구성도
서브버전은 클라이언트/서버 구조로 설계되어 있으므로 전체 아키텍처는 아래와 같은 구성을 갖는다.
주요 용어
- 저장소(repository) - 프로젝트 파일들의 모든 변경을 담은 중앙 저장소. 저장소에 연결하기 위해서는 svn protocol 을 구현한 client(command line, tortoisesvn, eclipse의 svn plugin 등)을 사용할 수 있다. 저장소는 안전하고 신뢰된 시스템에 위치시켜야 하고 주기적으로 백업해야 한다.
- 임포트(Import) - svn 의 저장소에 PC 에 있는 프로젝트 디렉터리를 등록하는 절차. 프로젝트의 폴더 구성에 맞게 하위 폴더도 등록하며 import 가 완료되면 저장소에서 체크아웃을 하여 PC 에 저장소의 프로젝트 사본을 만들어야 한다. 성공적으로 import 가 끝났다면 PC에 있는 작업본은 삭제해도 된다.
- 체크아웃(Check out) - 저장소에 프로젝트 소스를 개발자 PC 로 내려 받는 작업.
- 작업 사본(Working Copy) - 저장소에서 체크아웃하여 내려 받은 Local 에 존재하는 사본. 커밋을 하기 전에는 저장소에 변경이 반영되지 않으므로 다른 개발자에게 영향을 주지 않고 작업을 진행할 수 있으며 작업후 커밋하여 작업 사본의 변경 내역을 저장소에 반영할 수 있다.
- 익스포트(Export) - Local 에 있는 작업본의 svn metadata 를 정리하고 깨끗한 상태의 소스로 내보내는 작업. 소스를 외부에 전달할 경우등에 유용하다.
- 커밋(Commit) - 내가 작업한 내용을 저장소에 올려서 반영하는 작업.
- 업데이트(Update) - 저장소에서 변경된 내용을 받아서 내 작업
- 병합(Merge) - 한 개의 파일의 서로 다른 내용을 하나로 합치는 작업. 개별 파일에 대해서 하기도 하지만 특정 revision 의 파일묶음에 대해서 적용할 수도 있다.
- 충돌(Conflict) - 작업 내용을 커밋할때 동일한 소스에 대해 다른 이가 작업한 내용이 내가 작업한 것과 다른 부분을 고쳤다면(Ex: hello.java 의 소스에 printHello(), printWorld() 라는 두 개의 메소드가 있을때 개발자 A는 printHello를 수정하고 개발자 B는 printWorld 를 수정) svn 은 자동으로 해당 소스를 병합한다. 동일 부분을 다르게 고쳤다면(Ex: 개발자 A, B가 둘 다 printHello() 를 수정) svn 서버는 어떤 버전을 기준으로 병합할 지 알수가 없으므로 에러를 발생시킨다. 이런 상황을 충돌이라 하고 개발자가 수작업으로 병합을 해야 한다.
리비전(Revisions) - 저장소에서 commit 후 변경이 적용된 특정 시점의 상태. svn 의 리비전은 해당 저장소에서 유일한 번호의 숫자이며 커밋마다 1 씩 증가한다. 저장소를 생성하면 최초의 리비전은 0 이 된다.
- 트렁크(trunk) - 프로젝트의 메인 소스를 저정하는 경로. 프로젝트의 최초 버전 개발시나 개발이 끝난후 안정화된 버전의 소스를 트렁크에 넣고 관리한다.
- 태그(tag) - 프로젝트의 마일스톤(milestone) 이나 제품의 버전(Ex: v1.0)등 의미있는 사건들이 발생하는 리비전이 있을 수 있다. svn 에서 리비전은 숫자이므로 의미있는 사건과 리비전을 연계해서 기억하기는 힘들다. 이때 꼬리표로 특정 리비전에 식별할 수 있는 문자열을 붙이면 손쉽게 기억할 수 있다. (Ex. "r365 에서 수정한 기능이 뭐지" 보다 "0.8 버전에서 수정한 기능이 뭐지" 가 더 의사소통이 명확함)
브랜치(Branch) - 소스를 많이 수정해야 하는 기능이나 버그 수정, 새 버전 개발같이 큰 변경을 요구하는 작업을 할 경우 소스 변경이 트렁크에 영향을 미치지 않도록 분리하는 기능. svn 은 가지치기시 전체 소스를 복사하지 않고 symbolic link 로 처리하여 빠르게 처리가 가능하다.
