이에 버전관리(version control) 또는 소스코드관리(source code control)에 대한 고민을 풀어 보고자 한다.
먼저 누구나 공감(?)할 수 있는 장점을 나열해 보자
1. 과거로의 여행의 자유 (불행하게도 미래는 안된다.. -,.-;;)
- 자신의 작성한 코드의 한시간 전, 하루 전, 또는 한 달전으로 언제든지 롤백이 가능하다.
2. 코드의 보호
- 팀단위로 작업시 한번씩 스팀팩 받아 본 경험이 있겠지만 열심히 만든 코드를 누군가 덮어쓰기를
할 수 있는 여지를 만들지 않는다.
3. 코드의 발자국
- 코드가 만들어진 역사를 편하게 볼 수 있다. ( 역사를 이해하면 미래를 예측할 수 있다나....)
4. 코드 작성과 동시에 제품 탄생
- 약간에 과장이 있기는 하지만 하루하루 또는 일정한 단위로 자동 빌드 및 릴리즈가 가능한 시스템 에서는 반드시 필요하기는 하다.
5. 프로젝트 이력
- 버전관리를 이용하면 프로젝트가 특정한 날짜에 어떻게 진행되고 있었는지를 알 수 있다. (개발자
가 오늘은 몇라인을 코딩했을까? .. ^^!)
지금까지 글에서 버전관리를 위한 특정 프로그램을 언급하지 않았다. 이제 서브저번에 대해서 이야기 해보자. 왜 버전관리 툴롴써 서버버전을 사용하는 것일까?
서버버전 프로젝트는 CVS에 엄청난 경험이 있는 개발자들이 시작했다. 이들은 CVS 결점을 잘 알고 있었고 높은 성능과 현시대에 부응하는 버전 관리시스템을 설계했다.
서버버전의 특징적인 기능은 다음과 같다.
1. 서버버전은 파일들 뿐만 아니라 디렉토리와 메타데이터 까지 버전관리하는 객체로 본다.
: 여기서 메타데이터는 파일과 디렉토리와 관련 있는 서버버전 프로퍼티 정의 파일이다. 따라서 이
메타데이터가 관리됨으로써 서버버전이 어떻게 파일을 다루는지, 키워드 확장등을 광범위하게 제
어 할 수 있다.
2. 서버버전은 atomic commit을 지원한다.
: 서버버전은 사용자가 커밋을 하면 전체변화가 성공적으로 반영되든지, 아니면 취소되거나 롤백된
다. 어중간한 상태는 없다. 이것의 이점은 모든 개발자가 저장소의 동일한 뷰를 바라볼수 있다는 것
이다. atomic commit 과정의 일부로써 서버버전은 모든 변경된 내용을 revision (= changeset) 이
라는 불리는 것으로 그룹핑한다. 그리고 revision number로 할당한다. 이 그룹핑에 의해 많은 변경
파일들이 하나의 논리적 단위로 관리될 수 있다.
3. 서버버전은 똑똑한 네트워킹을 지원한다.
: SSH 지원, Apache Web Server 연동 지원등의 다양한 옵션과 효과적인 네트워크 프로토콜을 사
용한다.
4. 부하가 적은 branching, tagging, Merging을 지원한다.
: CVS의 경우 branching과 labeling은 서버에 접근해서 저장소의 모든 파일들을수정해야하는 부담
스러운 작업이다. 이런작업을 효울적인 데이터베이스 모델을 이용하여 적은 비용으로 작업이 가
능하다.
5. 서버버전은 다양한 플랫폼에서 운영가능하다.
: 특히 윈도우 환경에서도 잘 운영되며, 다른 머신으로 이전 또한 한번에 가능하다.
( 진입장벽을 깨버린 중요한 요소이다. )
댓글 없음:
댓글 쓰기