svn 위의 git 맛보기

회사에서 두 가지 SCM을 쓰고 있는데 —_ 물론 각기 다른 프로젝트에서_ — 다른건 다 제쳐놓고 소스 리포지터리 공간만 따지고 보면 거대한 공간을 쓴다. 작년에 만들어진 소스 저장소 서버가 반 년 후에 하드 용량이 2배가 되었고(꽉차서 하드풀이 났음), 다시 1년 후에 약 6배의 용량으로 증설되었다.

이유는 매우 단순하다. branch 기능 때문 perforce나 subversion(svn) 모두 branch나 tag(perforce는 COW 같은 일을 하기 때문에 무조건 늘어나는 것은 아니지만)를 만들면 사실상 해당 파일들을** 복사**해버리기 때문에 용량이 쭉쭉 늘어난다. 게다가 소스 저장소에 설치 파일(이걸 왜!) 같은 것도 커밋하는 사람들이 있기에(…). 

그런 이유에서(다른 이유도 많기야 하지만) 저장소 공간을 매우 효율적으로 쓴다는 git 에 다시 눈을 돌리게 되었다. 일단 사용 경험을 좀 뽑아내고자 설치하고 하루 동안 썼는데, 나름대로 만족스런 점/불만족스러운 점이 묘하게 조화를 이루고 있다. git 개발자들이 “다른 라이브러리 의존성이 없는 작은 툴셋"이라고 주장하는게 맞는 말이긴 한데, 대신 이 툴셋의 기반인 perl이나 몇몇 *nix 시스템 콜들이 윈도우로 완전히 포팅된게 아니라서 Win32에서 개발하는 사람들 입장에선 좀 쓰기 안좋다.

일단 SVN 사용자를 위한 튜토리얼을 읽고 시작했고 + 글 아랫쪽에 써놓은 git-svn rebase 문제는 여길 보고 해결했다.

그리고 encoding-neutral 하다는데 — 실제로 소스코드를 스캐닝한 xeno군도 strlen밖에 안보였다한다 — svn위에서 git을 쓴 경우 Win32에서 한글 파일들이 깨지는 문제가 있었다. 이건 이유가 불명? 진지하게 쓰게되면 정말 좀 추적해봐야할듯…

뭐 용량은 확실히 적은 것 같고 — branch를 따도 기존 트리에다 약간의 농간?을 부리면 된다 — 속도는 빠른지 모르겠다. SVN이 커지면 느리고, perforce가 용량 증가에는 잘 버틴단 느낌인데, git은 그 사이 정도의 속도란 느낌이었음. git-svn 을 쓰는거라 그런지 모르겠는데, git clone으로 전체 트리를 오프라인 복사하려 했더니 메모리 할당 실패(sbrk() 실패)로 크래쉬 -_-;

git fetch로 HEAD 리비젼만 따와서 하루동안 작업했는데, git status -> git add & dcommit 으로 일련의 커밋을 하는건 맘에 든다. 변경 수준을 몇 가지 통계로 볼 수 있다는 점도 좋고. 사실 제일 좋은건 rollback 할 수단이 여러가지란 점과, 로컬 커밋/중앙 SVN 서버 커밋을 분리할 수 있다는 점이지만 이건 아직 크게 와닿진 않는다.

svn을 git처럼 쓰려고 git-svn을 쓰기 시작한건데(일단 msysGit으로), svn update에 해당하는 git-svn rebase가 (pull/push를 못쓴다. git native가 아니거든 ㅠㅠ) 내가 변경한 것 + 다른 사람이 변경한게 섞이면 귀찮은 과정을 겪어야 한다.

git stash
git svn rebase
git stash apply
git stash clear # 안해주면 다음git stash가 불평(?)한다… 

로 한단계 건너건너 가야한다는 게 좀 그렇네¹.

앞으로 한 일주 써보고 git-svn을 계속 이용할질 고민하고 + 만약 이게 distributed SCM 이라서 쓸모있는거랑 용량 효율이 적당한것 같으면 실제 저장소 서버에도 일부 적용할 생각을 해봐야겠다.