svn 위의 git 맛보기

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

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

그런 이유에서(다른 이유도 많기야 하지만) 저장소 공간을 매우 효율적으로 쓴다는 git ((예전에 git on svn을 한 번 시도했었는데, 그 때는 뭔가 잘 안되서 포기했었다)) 에 다시 눈을 돌리게 되었다. 일단 사용 경험을 좀 뽑아내고자 설치하고 하루 동안 썼는데, 나름대로 만족스런 점/불만족스러운 점이 묘하게 조화를 이루고 있다. 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가 불평(?)한다… 

로 한단계 건너건너 가야한다는 게 좀 -_-;; ((같은 merge가 아니기 때문에 원본트리 -> 현재 상태로의 패치를 만들고, 이를 저장한 후, SVN 저장소를 업데이트하고, 다시 이 패치를 적용하는거다)) 

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