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
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
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으로 넘어가면서 혼란이 생기더군요.. 왜? branch와 tag가 없어졌을까?... 그러면 그전에 하던 작업은 어떻게 하라고...?
답글삭제위키처럼 저기능 고효율을 따른게 아닐까 싶습니다.
답글삭제branch와 tag를 copy로 구현할 수 있으니까 따로 분리해 두지 않은 것 이지요. 저처럼 SVN을 먼저 접한 사람은 CVS에 branch와 tag가 따로 있는게 더 어색하게 느껴지네요.
또한 svn에서의 copy가 cvs에서의 branch, tag보다 빠릅니다.
tag된걸 사용자가 checkin 할 수 있다는 점은, 디렉토리별 권한을 조절해 막을 수 있습니다. CMS관리자겐 조금 복잡해 지겠지만 End-developer?는 실수할 우려가 없어지죠.
길고 복잡한 명령행 입력은 tortoiseSVN 이나 nautilusSVN같은 GUI 프론트엔드로 극복할 수 있죠.
왜 사용자가 tag되어 있는 파일들을 checkout받아서 고쳐서 커밋할 수 있는 걸까?
답글삭제->가령 프로젝트 초기에 오리지날이란 태그를 붙여버렸는데 나중에가서 오리지날에 다른 소스도 포함됐어야 된다는 사실이 발견됐다고 칩시다. cvs같은 경우는 오리지날 태그 소스받아서 커밋하면 헤드에 커밋이 되서 버젼 충돌이 일어납니다.(즉 커밋할 장소가 없다는거죠).
cvs에서는 이런경우와 같이 처음에는 수정할 필요가 없다고 생각해서 태그로 작성했지만 나중에 가서야 수정할 필요가 생겨서 브랜치로 만들껄 하고 후회하는 경우가 종종 있습니다.
왜 branch 아래에 있는 디렉토리를 다른 branch로 mv할 수 있는 걸까
->이미 branch를 만들어 작업중인데 나중에가서 다른 구조로 branch를 하는게 더 구조적으로 적합하다는 판단이 섰을때 고칠수없다면 괴롭습니다. 새로만들게되면 기존 작업한 이력들 다 날라가고요..
결론적으로 말씀드리자면 레포의 구조가 이상하는것이 발견됐을때 나중에서라도 수정할수있는 편의성을 높이기 위함이 아닐까요 인간인지라 처음부터 완벽한 구조로 설계해서 커밋하는 불가능하니까요. 개발 이력 다 날리고 레포를 새로 만드는게 얼마나 치명적인지는 잘 아실겁니다.
@startail - 2009/12/12 01:46
답글삭제예를 드신 태그가 잘못됐을 때, 고친 부분 다시 태그 달면 되죠. 브랜치를 옮겨야 하는 경우도 예를 드셨는데, 브랜치에 트리 구조를 생각해야 되는 것부터가 SVN이니까 필요한 것 뿐이죠.
SVN에서 그렇게 할 수 있는 이유는, 생각하신 것처럼 편의성이 아니라 지나치게 일반화를 시켰기 때문입니다. 태깅과 브랜칭 작업을 path로 일반화하니까 지나친 자유도가 생긴 거예요.