버전 컨트롤 시스템 황당
사용기 2007/11/20 03:58- 왜 cvs merge는 merge하지 않는 걸까?
- 왜 svn move는 move하지 않는 걸까?
- 왜 git revert는 revert하지 않는 걸까?
cvs/subversion에 익숙해 지고 나서 착각하기 쉽지만 git revert는 로컬 변경사항을 버리는 명령이 아니다. 명령어부터 시작해서 지난 버전컨트롤 프로그램들의 관례를 무시한 git, 알아갈 수록 당황스럽다.
'Subversion'에 해당되는 글 3건버전 컨트롤 시스템 황당사용기 2007/11/20 03:58 버전 컨트롤 명령어를 사용하면서 이해가 힘들었던 몇가지,
cvs/subversion에 익숙해 지고 나서 착각하기 쉽지만 git revert는 로컬 변경사항을 버리는 명령이 아니다. 명령어부터 시작해서 지난 버전컨트롤 프로그램들의 관례를 무시한 git, 알아갈 수록 당황스럽다. SVN branching/tagging사용기 2007/06/06 10:12 왜 CVS에서 한 개의 이름으로 표현되었던 branch와 tag가 SVN에서는 repository의 directory copy로 바뀐 걸까? branch/tag/merge가 난무하는 프로젝트에서는 이렇게 branch와 tag에 사용자가 정의한 policy가 동원되어야 하는 점은 큰 불편으로 다가온다. 예를 들어 SVN 매뉴얼의 가이드라인을 따라서 branch를 /branches, tag를 /tags에 copy한다고 할 때, 무슨 branch가 있는 지 살펴본 다음 어떤 branch와 trunk 사이의 diff를 뽑아내고 싶다라면
svn info (URL이 뭐더라?) svn ls svn+ssh://server.name/project/branches/ (무슨 branch가 있더라?) svn diff svn+ssh://server.name/project/branches/branch-stable svn+ssh://server.name/project/trunk 문제는 branch/tag/merge와 관련된 작업을 하기 위한 모든 명령에 URI를 입력해야 한다는 점이다. 그리고 매번 이 project가 branch/tag에 어떤 copy policy를 쓰고 있는지 상기해야 한다.
svn merge svn+ssh://server.name/project/tags/branch-stable-merged-YYYYMMDD \
svn+ssh://server.name/project/branches/branch-stable merge할 때도 역시 repository의 위치와 project의 tag/branch policy를 머리속에 떠올리면서 절대 URI를 입력해야 한다. merge한 포인트가 어디인지 기록이 남지 않는다는 (그래서 별도 tag로 남기기도 하는) 점은 CVS랑 똑같으니까 어쩔 수 없다고 해도, 더 명령을 입력하기 불편해졌다. 애초부터 tag와 branch가 directory와 copy라는 단일한 기능으로 커버한다는 게 어색한 이야기이다. CVS에서는 분명한 branch와 tag 기능들을 (CVS의 branch가 딱히 쓰기 좋은 것도 아니지만) SVN에서는 directory 구조와 copy로 일반화하면서 구분이 없어지고 사용자의 재량에 맡겨 버리고 말았다. 왜 사용자가 tag되어 있는 파일들을 checkout받아서 고쳐서 커밋할 수 있는 걸까? 왜 branch 아래에 있는 디렉토리를 다른 branch로 mv할 수 있는 걸까? 물론 이렇게 쓰면 안 되지만, 이렇게 쓰면 안 된다는 정책을 소프트웨어에서 제공하는 게 아니라 사용자의 정책에 맡겨 놓는 바람에 사용하기가 복잡해졌다. CVS에서 Subversion으로 바꾸기, 좋을까사용기 2007/02/04 06:32 그놈 CVS가 subversion으로 전환한 이후 얼마가 지났으나 사실 큰 장점을 못 느끼는 게 사실이다. 애초에 subversion은 cvs와 같은 모델의 vc를 만들면서 cvs의 단점을 보완하는 게 목적이었고, 사용법부터 시작해서 크게 다르지 않다. 흔히 cvs와 비교해 장점이라고 하는 것들을 살펴보면:
1. renaming, file property 따위의 versioning 안정된 프로젝트일 수록 디렉토리 이름을 바꾸는 일은 그리 많지 않다. (과거에 회사에서 오타가 섞인 이름마저 끝내 바꾸지 못했던 기억이 있다.) 2. atomic commit/tag CVS의 commit/tag가 atomic이 아니라고 해서 문제가 될 상황도 별로 많지 않다. 오히려 (사람이 직접 신경 쓰지 않으면 해결할 방법이 없는) 논리적인 충돌이 더 많이 발생한다. 3. lightweight branching 이 부분은 서버의 로드와 관련된 것이므로, 알기 어렵다. 분명히 장점이다. 4. diff/revert에 네트워크 연결이 필요없다 이것만은 확실히 좋다는 걸 느낀다. cvs는 diff를 할 때마다 해당 파일의 전체 내용을 전송받는데, 유럽에 있는 gnome cvs 서버에서 이 내용을 받는 건 만만치 않은 일이다. 심심풀이 해커도 그리 느끼는데 업으로 삼는 사람들은 더더욱 좋다고 생각할 듯. subversion은 cvs와 비교해 분명한 장점이 있으나 멀쩡히 안정적으로 잘 돌아가는 닫힌 프로젝트의 vcs를 cvs에서 svn으로 바꾸는 일은 별로 추천하지 못하겠다. 옮겨가는 데 별로 무리도 없지만 얻는 장점도 별로 없기 때문이다. (gnome처럼 vcs 이용자가 워낙 많고 세계 여기저기에 퍼져 있는 경우라면 위의 3/4 항목으로 큰 이득을 볼 수도 있겠지만) |