언제 한번 분산형 VCS들을 소개하려고 했었는데, krisna님의 요청도 있고 해서 이렇게 글을 한번 써봅니다.

현재 분산형 VCS들은 대략 10여가지 정도가 있는데, 상용으로는 Perforce, Bitkeeper등이 있고, 오픈소스로는 이번에 소개할 Mercurial과, Bazaar, monotone, Darcs, git, SVK 등이 있습니다.

이제 Mercurial에 대해 알아보도록 하겠습니다. 일단 Mercurial은 수은이라는 뜻이죠, 그래서 명령어도 수은의 원소기호인 hg입니다. 아주 Geek한 작명이라 생각합니다.

Mercurial은 분산형 VCS라 CVS나 Subversion 처럼 저장소와 작업 디렉토리(Working Copy)의 구분이 없습니다. 그래서 소스를 수정하여 커밋을 하면 원격에 있는 저장소에 커밋 되는것이 아니라 현재 작업하는 디렉토리에 커밋이 되게 됩니다.

이 커밋을 할때마다 생기는 것이 체인지셋(changeset)인데 Subversion의 리비전 개념과 같이 여러 파일을 동시에 커밋할 수가 있고(atomic commit), 전체 리비전 번호도 붙습니다. 다만 Subversion과 다른 것이 체인지셋마다 고유의 sha1 해쉬값이 붙습니다. 그리고 어느 체인지셋에서 갈라져 나왔는지도 추적이 가능합니다.

중앙집중형 VCS들은 소스를 원격에서 받아올때 체크아웃 명령을 사용하여 받아오지만 Mercurial은 클론(hg clone) 명령을 통해 원격이나 로컬에 있는 저장소를 그대로 복사해옵니다. 그리고 이 복사해온 저장소에 커밋을 하여 작업을 하게 됩니다.

그러면 클론 명령으로 복사해온 저장소에 커밋을 했는데, 원격 저장소에 반영은 어떻게 하냐는 의문점이 생깁니다. 여기서 분산형 VCS의 특징이 나오는데, Mercurial에서는 hg push 명령으로 원격 저장소에 변경된 체인지셋을 밀어 넣습니다. 반대로 원격 저장소에서 변경된 체인지셋을 받아오려면 hg pull 명령으로 가져옵니다. 특정 리비전을 가져오려면 hg update 명령을 이용하면 됩니다

Mercurial의 특징 중 하나가 hg serve 명령을 이용하면 자체 웹서버가 실행되면서 ViewVC 같은 웹 인터페이스를 바로 볼 수 있다는 것입니다. 이렇게 동작시킨 서버를 통해 원격에서 hg clone 명령을 이용하여 저장소를 가져갈 수 있습니다.

현재 Subversion의 단점들이라는 글에서 Subversion의 단점인 벤더 브랜치 문제를 들었는데, Mercurial 같은 분산형 VCS에서는 저장소를 통째로 클론해오기 때문에 로그와 변경사항도 그대로 남아있고, 그 저장소 안에서 개인적으로 수정사항이 계속 추가될 수 있다는 것입니다.

Trac에서도 Mercurial을 잘 지원하고 있어서 여러가지로 활용이 가능합니다. TracMercurial

Mercurial에 대한 자세한 설명은 Understanding Mercurial을 참고하시면 됩니다. 체인지셋들이 어떻게 진행되어 나가는지 그림으로 잘 설명하고 있습니다.

이제 CVS에서 점점 Subversion으로 대세가 기울어가고 있는 가운데, 현재 Subversion이 직면한 문제점들에 대해서 말해보고자 합니다.

1. 핵심 개발자의 이탈
콜랩넷 소속의 Subversion의 핵심 개발자 2명이 구글로 전직을 하는 바람에 (1),(2) 현재 개발이 상당히 더딘 상태입니다.

2. 네트워크 부하를 줄이기 위한 메타데이터가 성능의 발목을 잡는 상황
예전 CVS는 변경된 파일을 비교하는 경우에도 저장소 서버에 접속해 원본 파일을 받아와서 비교를 했습니다. 어떤 동작을 하더라도 서버와 많은 통신을 해야 해서, Subversion은 이것을 해결하고자 체크아웃을 할때 많은 메타데이터를 생성했습니다. 그래서 변경된 파일을 비교할때에는 서버와 통신을 하지 않고 바로 메타데이터와 비교를 합니다.

하지만 여기서 문제가 생기는 것이 작업물의 크기가 커질수록 메타데이터도 배로 늘어나기 때문에 성능이 엄청 떨어지게 됩니다. (한마디로 엄청 버벅대죠) 게다가 로그는 메타데이터로 저장하지 않고 서버에서 받아오기 때문에, 메타데이터가 커봤자 아무짝에 쓸모가 없는 상황이 되어 버립니다.

요즘 나오는 분산형 VCS들은 저장소 자체를 통채로 가져오기 때문에(clone) 네트워크 부하는 아예 없습니다. 그렇기 때문에 애초 Subversion의 의도 자체는 현재 별 실효성이 없습니다.

분산형과 중앙집중형의 장단점을 잘 반영하여 개발했으면 합니다.

3. 벤더 브랜치 문제
현재 Subversion은 벤더 브랜치라는 형태로 타 프로젝트 소스트리를 저장소 안에 관리할 수는 있습니다. 하지만 완전한 저장소끼리 병합이 되지 않기 때문에 로그 메시지와 변경사항이 다 날아가 버린다는 것입니다. 분산형 VCS에 비해 매우 불편한 부분입니다.

마치며, 저의 생각들
이런 단점들이 있긴 하지만, 현재로서는 Subversion은 지금까지 나온 VCS들 중에서 가장 많은 응용 솔루션들을 가지고 있고, 많이 쓰이고 있어서 쉽게 바뀌지는 않을 것입니다.

언젠가 혜성처럼 새로운 VCS가 나타나 Subversion을 Subversion하는 날이 올지도 모릅니다. 또는 VCS들의 춘추 전국시대가 도래할 수도 있고요. Subversion을 대체하려면 필수적인 것이 Windows용 GUI 쉘 익스텐션 클라이언트와 웹 인터페이스(이슈 트래커 통합 환경)이라고 단언할 수 있습니다.

Windows에서 Subversion을 사용할때 TortoiseSVN은 이제 필수 프로그램이 되어버렸습니다.

TortoiseSVN은 전형적인 1인 독재형 오픈소스 프로젝트지만 거의 완벽하다 할 정도의 완성도를 보여주고 있습니다.

이건 제 생각인데 콜랩이 TortoiseSVN 개발자에게 전폭적인 지원을 해주고 있거나 콜랩 직원일 수도 있습니다.(확인된 바는 없지만...) 취미로 한다면 이렇게 오랬동안 꾸준하게 풀타임 개발을 할 수가 없을 것입니다.(마크 셔틀워쓰가 아닌 이상 ) 매일 나이틀리 빌드까지 만들어가면서 배포를 하고 있으니, 의혹(?)은 더욱 증폭됩니다.

TortoiseSVN 추측은 이정도로 하고, TortoiseSVN 홈페이지를 둘러 보던 중 VisualSVN이라는 것을 알게 되었습니다. 이 VisualSVN은 Microsoft Visual Studio 2003, 2005에 플러그인 형태로 실행되는 Subversion 클라이언트 입니다.

그런데 아주 황당한 것은 TortoiseSVN을 꼭 설치해야 한다는 것입니다. 뭐 저는 TortoiseSVN이 예전 부터 설치가 되어 있어서 막힘 없이 설치가 됐는데, 이때부터 뭔가 이상했습니다. VisualSVN을 설치하고 Visual Studio를 실행해 보니 메뉴에는 VisualSVN 메뉴가 있었습니다. 거기에 있는 명령들을 실행해보자 마자 느낀 황당함은 바로, TortoiseSVN의 체크아웃, 커밋, 로그창이 뜬다는 것이었습니다.

VisualSVN은 아무 기능도 하지 않고 단순히 Visual Studio에 메뉴를 생성해주고 TortoiseSVN을 불러주는 일 밖에 하지 않는다는 것입니다.(아, 따로 해주는 일이 있긴 하군요, 파일 수정 상태를 체크해서 솔루션 창에 표시해주는 것 말이죠) 이걸 49달러를 받고 팔고 있습니다.

개발한 프로그램을 돈받고 파는 것 가지고 뭐라고 할 수는 없는 노릇이지만, 이 상황을 보고 생각난 말이 재주는 곰이 넘고 돈은 사람이 번다는 말이었습니다.

TortoiseSVN이 워낙 많이 사용되고 있다 보니 이런 희한한 경우도 나오고 있습니다.

VisualSVN 말고도 Visual Studio 플러그인 형태의 Subversion 클라이언트가 예전부터 있긴 있었습니다. AnkhSVN이라고, 이건 완성도도 매우 떨어지고 한 3년째 버전 1.0도 내지 못하고 있습니다. 그래서 그런지 VisualSVN이 나온것 같기도 하고요.

곰이 될 것이냐 사람이 될 것이냐 그것이 문제로다.~