서브버전(Subversion, 소프트웨어 버전 관리 시스템)
원래 CVS 를 사용했으나 디렉토리의 이동이나 이름 변경 등과 같은 한계점 때문에 SVN 이라는 개량 시스템이 나오게 되었다.
한 프로젝트의 소스 코드를 하나의 중앙 저장소(서버)에 위치하고, 해당 저장소는 포함하고 있는 파일과 디렉토리의 모든 변경 사항을 기억하고 있게 된다. 이러한 변경 사항에 대해 예전으로 되돌리거나 어떻게 변화했는지에 대한 이력을 확인하는 등 다양한 관리를 할 수 있다.
서브버전은 여러 컴퓨터에서 네트워크를 통해 접근할 수 있으며 (권한에 따른) 다양한 사람들이 파일을 수정할 수 있도록 하여 협업이 가능케 한다. 모든 작업에 자동으로 버전이 매겨지므로 만일 잘못된 수정이 가해졌더라도 쉽게 되돌릴 수 있다.
가장 원시적인 형태의 Versioning Model은 파일의 직접 공유이다.
A 와 B 가 임의의 저장소에서 동일한 파일을 참조하여 작업할 때, A 가 수정한 내용과 B 가 수정한 내용은 동시에 반영/보존될 수 없다.
이러한 한계를 극복한 것으로 Lock-Modify-Unlock Model 이 있는데 이는 수정자 A가 수정할 파일을 다른 수정자 B가 수정할 수 없도록 잠그고(Lock) 수정(Modify) 완료 후 잠금해제(Unlock)하는 형태이다. 하지만 수정자 A 가 수정하는 동안에는 다른 수정자들은 해당 파일을 읽기 밖에(Read Only) 할 수 없고, 수정자 A 가 잠금 해제할 수 없는 상황이 되어 버리면 누구도 해당 파일에 손댈 수 없으며, 수정자 A, B 가 각각 서로를 참조하는 파일 1, 2 를 잠그고 수정하는 경우 참조의 균일성이 깨어질 위험이 있다.
서브버전은 Copy-Modify-Merge 모델을 사용한다.
각각의 수정자는 서버 저장소에서 개인적인 작업 복사본을 만들어 작업하며 수정이 완료된 시점에 저장소에 변경사항을 반영한다. 이 때 변경 대상에 대해 다른 수정자에 의한 변경사항이 존재한다면 이를 통지 받고 자신의 복사/수정본과 병합할 수 있다. 병합 시 새로운 변경사항 중 자신이 수정한 부분과 충돌이 일어나는 부분에 대해서는 수정자가 다른 수정자와의 의견 교환 후 수동으로 선택한다.
버전관리를 사용하는 이유
- 여러 사람이 한 프로젝트의 소스 코드를 관리하기 위해
- 소스 코드의 변경 사항을 추적 (누가 수정했는지, 어떻게 수정했는지) 하기 위해
- 프로젝트의 영향을 최소화 하면서 새로운 부분 개발 (Branch) 하기 위해
- 새롭게 개발한 부분의 검증 후 프로젝트에 적용 (Merge) 하기 위해
- 대규모 수정 작업을 더욱 안전하게 진행하기 위해
SVN 의 일반적인 흐름
- 프로젝트 P 에 대해 SVN 을 사용하기 위해 Repository 에 최초 자료를 Import 한다.
- 사용자 A 는 Repository 에 접속하여 수정하려는 파일을 CheckOut 한다.
- 수정완료 후 Commit 을 통해 수정 내용을 저장소에 반영하기 전, 수정 대상에 대한 변경내용이 있다면 Update 한다.
- Commit 하여 저장소에 수정 내용을 반영한다.
SVN 의 기본 용어 설명
Repository : 서버 저장소
Working Copy : Repository 에서 받은 개인적인 작업 복사본
Import : 최초로 Repository 에 자료를 올리는 행위
Export : Repository 에서 자료를 내려 받는 행위, 버전 관리 정보 제외
CheckOut : Repository 에서 자료를 내려 받는 행위, 버전 관리 정보 포함
Commit : 개인 작업 영역에서의 변경내역을 Repository 에 반영
Revision : 갱신 번호. 저장소에서의 수정이 발생할 때 마다 자동으로 증가
Trunk : 개발 가지들 중에 가장 중심이 되는 줄기
Branch : 특정 버전으로의 뻗어나가기
Tag : 개발 버전의 스냅샷
Branch
한 프로젝트가 특정 시점의 버전부터 둘 이상의 독립적인 프로젝트로 분기될 때 이를 Branch 라 한다.
Branch 는 언제나 특정 시점의 데이터의 복사본으로부터 생성되어 그 자신만의 히스토리를 시작한다. 서브버전은 복사된 새 Branch 에 대해 원본의 어떤 데이터(Trunk)와 관련이 있는지 기억하며 한 쪽의 변경사항을 다른 쪽에 복사하는 것과 같은 개발 부분의 혼합/매치를 가능하게 한다.
Branch 는 이러한 독립적인 새 프로젝트를 위한 경우 외에도 한 수정자의 '오랜 시간이 걸리거나 프로젝트의 많은 부분이 변경되는 수정 작업' 의 경우에도 사용될 수 있다.
Merge
Merge 는 두 저장소의 트리를 비교하고 그 차이점을 작업본에 적용한다. 임의의 Branch 에서 수정 작업의 완료 후 이를 Trunk 에 반영하고 싶을 때에는 먼저 해당 Branch 를 최신 Trunk HEAD 로 Update 해야 한다. 이 후에 Branch 와 Trunk 를 Merge 해야 Branch 와 Trunk 사이에 오직 수정자가 Branch 에 가한 수정사항 만큼만 Merge 할 수 있다. 즉, 내 Branch 의 변경사항이 일어나는 동안 변화한 Trunk 의 상태를 내 Branch 에 먼저 반영하고 그 이후에 내 Branch 의 변경사항을 Trunk 와 Merge 해야 한다는 의미이다.
아래는 KLDPWiki 에 나와있는 일부 내용을 그대로 옮긴 것이다.
개발자의 브랜치 사용패턴
대부분의 소프트웨어는 전형적인 라이프사이클 - 코딩, 테스트, 릴리즈, 반복 - 이 있는데 여기에는 두 가지 문제점이 있습니다. 우선, 개발자는 품질 인증팀이 릴리즈된 제품을 검사할 동안 기다려야만 합니다. 둘째 대부분의 팀은 구 버전과 릴리즈된 버전을 함께 서포트해야 합니다. 만일 최근에 버그가 발견되었다면 릴리즈된 제품에도 버그가 존재할것인데 사용자는 새로운 릴리즈를 기다리지 않고 즉시 버그가 수정되기를 바랄것입니다. 이때 버전관리가 필요한데 전형적인 프로세스는 다음과 같습니다:
- 개발자는 트렁크에 모든 새 작업을 올려놓는다. 매일 매일 수정사항이 트렁크에 커밋된다. 새 기능, 버그픽스 등등······.
- 트렁크를 릴리즈 브랜치로 카피한다. 개발팀이 생각하기에 제품을 릴리즈할 준비가 되었다고 생각할 때 트렁크를 브랜치로 카피한다. 예를 들어 /branches/1.0가 될것이다.
- 팀은 이와 병행해서 작업을 계속한다. 한 팀이 릴리즈 브랜치의 테스트를 할 때 , 다른 팀은 트렁크에서 계속 작업을 할 수 있다. 어느 쪽에서든 버그가 발견되면 버그픽스가 왔다갔다 할것이다. 하지만 어느 시점이 되면, 그런 프로세스는 멈추고 브랜치는 릴리즈 바로 직전의 최후 테스트 버전으로 고정될 것이다.
- 브랜치는 태그되고(tagged) 릴리즈된다. 테스트가 끝나면 /branches/1.0은 레퍼런스 스냅샷인 /tags/1.0.0으로 카피된다. 이 태그는 패키지화 되어 고객에게 릴리즈된다.
- 브랜치는 항상 유지 보수된다. 트렁크에서는 2.0버전의 작업이 계속된다해도, 버그픽스는 트렁크에서 /branches/1.0으로 계속 포팅된다. 일정량의 버그픽스가 쌓이면, 버전 1.0.1을 릴리즈하기로 결정한다. /branches/1.0은 /tags/1.0.1로 복사되고 태그는 또다시 패키지화 되어 고객에게 릴리즈된다.
이 모든 과정이 소프트웨어 개발에서 반복되는데, 2.0버전의 개발이 완료되면, 새로운 2.0버전 릴리즈 브랜치가 만들어지고, 테스트되고, 태그된 후 릴리즈 됩니다. 몇 년 후 저장소는 유지 보수되는 릴리즈 브랜치 여러 개와 최종 버전인 태그 여러 개가 남아있을 것입니다.
Tag
Tag 는 특정 시기의 프로젝트의 스냅샷을 의미한다. 보통 새로운 버전의 release 와 같은 의미 있는 시점에 사람들은 revision 번호 외에 직관적인 이름을 붙이길 원한다. 이 때 사용하는 것이 Tag 이다. 이렇듯 분류만 다를 뿐 시스템 안에서의 개념은 Branch 나 별 차이가 없다.
참고
