'Subversion'에 해당되는 글 3건

  1. 2007/11/20 버전 컨트롤 시스템 황당
  2. 2007/06/06 SVN branching/tagging (2)
  3. 2007/02/04 CVS에서 Subversion으로 바꾸기, 좋을까

버전 컨트롤 시스템 황당

사용기 2007/11/20 03:58
버전 컨트롤 명령어를 사용하면서 이해가 힘들었던 몇가지,
  • 왜 cvs merge는 merge하지 않는 걸까?
  • 왜 svn move는 move하지 않는 걸까?
  • 왜 git revert는 revert하지 않는 걸까?
merge는 또 다른 modify로 기록될 뿐이며, move는 delete와 add로 기록될 뿐이다.

cvs/subversion에 익숙해 지고 나서 착각하기 쉽지만 git revert는 로컬 변경사항을 버리는 명령이 아니다.  명령어부터 시작해서 지난 버전컨트롤 프로그램들의 관례를 무시한 git, 알아갈 수록 당황스럽다.

tags : bzr, git, SCM, Subversion
Trackback 0 : Comment 0

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할 수 있는 걸까?  물론 이렇게 쓰면 안 되지만, 이렇게 쓰면 안 된다는 정책을 소프트웨어에서 제공하는 게 아니라 사용자의 정책에 맡겨 놓는 바람에 사용하기가 복잡해졌다.

tags : branch, cvs, Subversion, tag
Trackback 0 : Comments 2

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 항목으로 큰 이득을 볼 수도 있겠지만)

Trackback 1 : Comment 0