Distributed Version Control System을 써볼까..

VCS(Version Control System)으로 Subversion(SVN)을 쓴지 꽤 되었는데, SVN이 없던 때는 어떻게 살았는지 이제는 기억도 안 날 정도로 의존도가 높아졌다. 원하면 언제든 과거의 어떤 시점에 파일이 어떤 내용이었는지를 쉽게 볼 수 있다는 건 작업물의 안전을 위해서 뿐 아니라, 나중에 그동안 한 일을 돌아보는데도 정말 편하기 때문이다. 프로그래밍에 관심이 있는 사람이라면 꼭 SVN이 아니라도 Perforce나 CVS 등등 뭔가 하나는 당연히 써야 하는 것이고, 그렇지 않더라도 history tracking이 필요한 문서를 다루는 사람(이를테면 글을 여러 차례 고쳐 쓰는 소설가)도 VCS를 써야한다고 생각하게 되었을 정도. 그림이건 문서건 고치고 저장한 다음에 고쳐지기 이전의 내용이 아쉬워 후회해 본 적이 있다면 당신도 어떤 형태로든 VCS를 써야하는 사람이다.

이렇게 SVN 의존도가 높아지면서 불거진 문제가 있는데, 그것은 SVN의 핵심인 '과거 기록'은 어딘가 한 군데의 저장소(repository)에 모두 모여있어서, 그 저장소에 접근할 방법이 없으면 내용을 꺼내볼 수도 집어넣을 수도 없다는 것이었다. 컴퓨터가 달랑 한대면 저장과 작업이 모두 한곳에서 일어나니 별 문제가 없지만, 사용하는 컴퓨터가 늘어나면 저장소용 서버를 24시간 돌리지 않는 이상 불편한데, 가정용 전력은 누진세가 ㄷㄷㄷ.... 게다가 노트북 들고 어디 잠시 나가기라도 하면 켜져있어도 연결이 쉽지 않으니 갈수록 이런 저런 귀찮은 일들이 생긴다. 그러다보니 요즘 유행인 DVCS, Distributed VCS에 자연히 관심이 가게 되었다.

DVCS의 내 용도에서의 장점은, "기존 VCS에서 유일했던 저장소를 필요한 모든 컴퓨터가 각자 따로 가지고 있고 여러 저장소 간의 동기화를 가끔 해주면 된다"는 점이다. 일단 작업에 사용하는 컴퓨터에 작업물의 과거의 기록은 모두 로컬 저장소에 담겨 있으니 네트웍이 아예 없는 환경에서도 과거에 대한 걱정은 끝. 그리고 여기서 만든 변경도 로컬 저장소에 그냥 담아버리면 되니 마찬가지로 깔끔하다.

반면 DVCS 때문에 생기는 없던 문제는 "동기화를 게을리하면 결국 서로 다른 여러 최신 파일들 때문에 머리만 아파진다"는 것인데, 출발이 같아도 각각의 로컬 저장소에서 여기선 이거 고치고 저기선 저거 고치고 한 상태를 오랜 기간 방치하면 결국 양쪽 다 최신이라고 부를 수 없는 미묘한 상태가 되어 계속 작업하기 애매해진단 말이다. 대개의 경우에는 특정 작업은 한곳에서 집중적으로 하기 마련이기 때문에 그 녀석을 중심으로 DVCS를 기존 VCS 스타일로 사용하면 조금 귀찮을 뿐이지 별 문제는 없다. 그 밖에 각자 다 싸짊어지고 다니는 스타일이다보니 소중한 하드 용량이 중복 낭비되는 문제도 있는데, 뭐 VCS에 넣을 만큼 중요한 자료는 여러 군데 저장되는게 오히려 자연스러운 것 아닌가.. 안전을 위해서.

아무튼 그래서 DVCS 중에 나름 유명한 Git을 한참 동안 들여다보며 이리저리 간을 보고 있었는데, 리눅스의 아버지가 만드셔서 그런지 윈도 지원이 하찮기 이를데 없는 Git은 SVN조차 TortoiseSVN shell extension의 막강 지원을 받아 쓰는 나에겐 알듯 말듯 하면서도 일상적으로 사용하기엔 너무 버거웠다. 그러던 차에 구글신께서도 "윈도에선 Git보단 Mercurial"이라 신탁을 내리시니 미련을 빨리 접고 Mercurial이나 뒤적여 봐야겠다.

구글의 DVCS 분석 - Git vs. Mercurial
어제 올라온 따끈따끈한 비교자료.

DVCS로 완전 이전하려면 아직도 갈 길이 먼 듯... 아직은 SVN이 짱.