git svn 동작이 거지같게 느껴지던 이유

실제론 svn으로 버젼관리를 하는 상황에서, git을 그 위에 쓰다보니 몇 가지 문제를 겪어야 했다.사실 몇 가지 점에서 git 의 동작을(혹은 git-svn의 동작을) 이해할 수가 없었는데, 최근에 Pragmatic Version Control using Git 을 구입해서 읽고나니 약간은 이해할 수 있게 되었다.

svn은 본질적으로 선형적인(linear) 이력(history) 를 갖는다. 즉,

1. 최초의 repository 상태가 있고,
2. 이 위에 새로운 변경 rev 2
3. 그 위에 새로운 변경이 더해져 rev 3
4. …
5. 마지막 변경이 가해져서 rev n

이 되는 형태다.

반대로 git은 각 개별 repository(DVCS니까)가 브랜치처럼 인지되고 / 변경 사항이 merge 되는 것 처럼 동작한다. 이에 따라 svn update에 대응되는 git 동작은 git pull이 아니라 git svn rebase (사실상은 git rebase) 만 가능해던 거다. 선형 이력이 아니라 브랜치간 merge 이력인 git이 svn 쪽에는 정상적인 svn 복사본인양 보여야하기에 이런 뻘짓(…)을 해야하는 거 -_-; ((git이 선형 이력이 안되는 이유…라기보단 git 사용 방식의 문제가 있는데. git은 기본적으로 branching이 매우 쉽다. 그리고 모든 류의 커밋은 merge 처럼 간주해서 처리한다. (분산인 이상은 당연한듯?) 그래서 이력 자체가 선형으로 생길래야 생길 수가 없다. 그래서 이걸 꽉 눌러짜서(…) git svn rebase로만 업데이트 해야 한다))

그리고 rebase 이기 때문에 커밋되지 않은 변경사항이 있으면 안되던 것 — 보통 git stash로 잠시 패치를 만들어 빼둔다 — 도 이해가 가게 되었다; svn update는 로컬에 변경사항이 있다면 묵시적인 머지를 시도하는 거지만,  git의 경우엔 그런 머지를 git의 관점에서 추적할 수단이 없기에 -_-;

개인적인 해결책(?)은 그냥 svn 브랜치 / 개발 브랜치 따로 쓰면서 git svn을 쓰는게 답이 아닐까 싶지만 -_-; 그럼 git svn이 복잡하기도 하고 merge/fast-forward 가 난무하게 되는 것도 사용자 입장에선 꽤나 귀찮은 일이 될테니 역시 이것도 답이 없나?

결국 git-svn의 동작이 이해안가고 / 맘에 안들던 이유는 git과 svn의 이력관리의 차이…때문인듯하다;

ps. 여튼 책을 읽으면서 커밋되지 않은 변경 사항이 branch 딸 때 어떻게 된다거나 / 써보지 않은 signing이나 k-merge 전략 같은 내용도 개념을 잡게 해줬다는 점에서는 괜찮았다. 그렇지만 책 자체가 튜토리얼치곤 양이 많고 / 리퍼런스치곤 볼륨이 부족하다는 점은 좀 아쉬비;