Version Control Systems

VCS(Version Control Systems)는 말 그대로 버전 관리를 위한 시스템을 말한다. 보통 소스 코드의 버전 관리가 주를 이루겠지만, 그외에도 개발에 소요된 문서, 이미지, 각종 바이너리 파일, 이슈 등 모든 주변 리소스가 버전 관리 대상이 될 수 있다.(아니, 그러해야 한다.) 버전 관리는 비록 사용하는 사람의 각별한 노력이 필요하겠지만 개발 리소스가 자라온 이력을 고스란히 담을 수 있다는 점에서 불의의 사고(소스 폴더 Shift-DEL 또는 rm -rf .)나 오판과 모험으로부터 개발자의 육신뿐 아니라 영혼(?)까지도 지켜줄 수 있는 타임머신이다. 그러므로, 하다 못해 'Hello, World!'를 출력해주는 단 한 줄짜리 코드를 작성할 때도 버전 관리는 필요하다.

개인적으로는 RCS -> CVS -> Subversion -> Mercurial/Bazaar-VCS/Git 순으로, 업무용으로는 과거에 주로 Subversion과 Perforce를 사용해왔고 현재는 Git를 사용하고 있는데, 경험에 기초해 간단하게 구분해보면 대략 아래와 같다. 좀 더 전문적이고 상세한 자료를 원한다면 Wikipedia:Revision_control 페이지를 참고하시라.

제 1 세대

선조님들!!

RCS

써본 지 너무 오래 되어 이제 기억도 잘 나지 않는다. 파일 단위로 리비전을 관리한다는 것 외에 딱히 기억나는 특징이 없음. (그 이상의 용도로 써보지 않았기 때문)

CVS

CVS는 RCS의 직계 자손 정도로 볼 수 있고 기능면에서도 분명 차이가 있지만 함께 1 세대로 묶은 건 거의 동시에 사용해보았기 때문이다. 파일 시스템 혹은 네트워크 서버에 중앙 저장소를 두고 클라이언트-서버 구조를 이루어 여러 명이 동시에 협업할 수 있는 버전 관리 시스템으로, lock 기반이 아닌 merge 기반 VCS 중 하나이다. 역사적으로 상당히 오래된 버전 관리 시스템이지만 여전히 많은 곳에서 사용 중인데, Emacs 모듈 SLIME이 그 중 하나다.

제 2 세대

개인적인 관점에서 2 세대 VCS의 가장 큰 변화는 파일 단위가 아닌 작업 단위(changeset) commit이 가능해졌다는 점이다. 목록에 따로 추가하지는 않았지만 Visual SourceSafe도 잠깐 써보았다. 그러나 생각했던 것보다 더 심각한 수준의 성능과 lock 기반 협업 방식, 지나친 네트워크 종속성 때문에 Subversion과 Perforce에 밀렸음. ClearCase는 가격 대비 효용성 문제로 도입이 중지됨.

Subversion

Subversion은 CVS의 장점을 그대로 계승하면서 작업 단위 commit을 지원하고 마지막으로 업데이트한 소스 코드의 원본을 별도로 유지하고 있기 때문에 중앙 서버에 연결할 필요 없이 작업 중인 코드의 달라진 점을 비교할 수 있어 무척 편리하다. 그러나, 버전 관리되는 폴더마다 .svn 하위 폴더를 두는 방식이라 파일이 수만에서 수십만 개되는 대형 프로젝트를 다루게 되면 최종 업데이트의 사본과 각종 버전 정보 파일들이 더해져 그 규모가 어마어마하게 변해버리기 때문에 심각한 성능 문제를 가져왔다. Apache Web Server 기반 서버를 구축하는 것도 가능하기 때문에 Mantis Bug Tracker나 Trac 등과 연동하여 팀내 중소규모 프로젝트를 위해 자주 사용했다.

Perforce

Subversion과 마찬가지로 중앙집중식 클라이언트-서버 모델로 구성된 버전 관리 시스템이다. 그러나, 버전 관리에 대한 최소한의 정보(정말 최소한이다. 서버에 연결하기 위한 몇 가지 설정 정보만 있으면 된다.)만 클라이언트에 유지할 뿐 나머지 모든 정보는 서버에 존재한다. 결국 서버에 부하가 집중되는 형태로 보이지만, 반대로 생각하면 클라이언트의 부담을 최소화하기 때문에 서버 성능이 충분하고 네트워크 환경이 좋다면 개발자 입장에서는 매우 쾌적한 버전 관리 도구이다. 실제로 지금 껏 경험해본 여러 VCS 중 가장 빨랐다. 대신, 네트워크에 문제가 생기면 모든 서비스 사용불가. Subversion과 다른 점 또 하나는 기본적으로 lock 기반이라는 점. 물론 동시 작업이 아예 불가능한 것은 아니고 적절한 수준에서 자동 merge도 지원한다. 화려하고 편리한 GUI 기반 클라이언트를 제공하는 것이 장점인데, 클라이언트 도구는 무료이고, 서버 도구는 지원 가능한 클라이언트 수에 비례하여 라이센스를 구매하는 상용 프로그램이다.

가장 인상 깊었던 것은 Label 기능. Perforce가 commit 단위인 changelist(changeset과 동일한 개념)와 함께 개별 파일의 revision 정보도 별도로 가지고 있기 때문에 특정 revision의 특정 파일들을 선별적으로 모아 목록으로 만드는 것이 가능하다. 이것이 바로 Label인데, 주로 어느 시점 이후의 commit 내용 중 일부를 배제하거나 몇 가지만 골라서 적용한 소스가 필요할 때 요긴하게 써먹을 수 있는 수단이다. 예를 들어, 제품의 특정 버전 출시 계획에 대해 '3월 28일 13시에 commit된 101234번 changelist를 기본으로 하는데, 101240과 101245 changelist는 포함해야 합니다.' 라는 요구 사항을 반영한 소스 묶음을 만들어낼 수 있다는 것이다.

제 3 세대

여기로 넘어오면서 발생한 가장 큰 변화는 분산(distributed)이라는 키워드가 붙었다는 것이다. 중앙집중식 저장소에서 분산 저장소 형배로 바뀐 것인데, 혼자 고립된 상태에서도 이전 commit 내용에 대해 이력 조회와 commit이 가능하다는 점에서 획기적이라고 할 수 있다. 이러한 특징은 branching과 merging이 활발하게 일어날 수 있는 오픈 소스에서 특히 그 빛을 발하고 있고, 사고나 악의적인 행위에 의한 개발 리소스의 완전 소멸 또는 소실에 대해 훨씬 견고한 버전 관리 체계를 구축할 수 있게 해주었다.

Mercurial

Python 기반으로 개발되었기 때문에 Windows, Linux, MacOSX, Solaris 등 다양한 OS 환경을 지원하고 있으며 여러 DVCS 중에서 Git과 함께 비교적 사용 빈도가 높은 편이다.

Bazaar-VCS

Bazaar는 DVCS에 대해 관심을 가지기 시작한 초기부터 Mercurial과 함께 줄곧 비교 대상(역시 Python 기반으로 개발되었고 다양한 OS 환경을 지원함)이 되어 왔으나 전체적인 사용 빈도에서 Mercurial보다는 조금 못하다. 성능 비교에서도 Mercurial이 조금 더 나은 면을 보여주고 있지만 QT 기반의 편리한 클라이언트 도구는 매우 쓸만하다. Subversion과 유사한 중앙집중식 저장소 형태도 지원하는 것이 특징. 근래에는 Emacs 개발 소스를 받기 위해 주로 사용하고 있다.

Git

리누스가 Linux Kernel의 버전 관리를 위해 개발한 DVCS로 여러 오픈 소스 프로젝트에서 활발하게 이용되고 있다. Mercurial과 Bazaar가 하나의 실행 명령에 옵션을 주는 식인 반면 Git은 역할 별로 여러 개의 작은 실행 명령으로 나누어져 있다.

Fossil

그다지 자주 사용하지는 않지만 Bug Tracking, Wiki, Web Interface 등이 단일 실행 파일 안에 응축되어 있는 일체형 VCS 겸 프로젝트 관리 시스템이라는 특징 때문에 나름 관심을 가지고 지켜보고 있다. Windows, Linux, MacOSX, OpenBSD 등 다양한 OS 환경을 지원하고 저장소를 위한 backend로 SQLite DB를 사용하는데 대규모 프로젝트에 아직 적용해본 적은 없어서 성능이 어느 정도인지는 모르겠음. 실행 파일 달랑 하나로 되어 있기 때문에 설치(사실 설치라고 말할 것도 없지만)가 무척 간편하고 더불어 이동성 또한 매우 뛰어나다. 소규모 개인 프로젝트를 관리하기에 꽤 좋은 도구라고 생각됨.

그외

  • Darcs: Haskell 기반으로 개발된 VCS. Haskell 사용자와 커뮤니티에서 주로 많이 사용된다고 함.

  • Monotone: DVCS에 관심을 가지던 초기에 알게 된 또 다른 VCS. 초기에 잠깐 사용해보았으나 이후 다른 VCS들에 밀려서 지금은 거의 사용하지 않고 있음.