그놈 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 from: subversion: 소프트웨어 버젼 관리 시스템
답글삭제흔히 많이들 사용하는 버젼 관리 시스템으로 cvs가 있다. 그리고 많은 분야에서 cvs를 이용해 버젼관리를 하고 있는 것으로 알고 있다. 개인적으로 cvs와 svn을 모두 사용해 보았다. 버젼관리 용도로 선택권이 있고, 둘 중 하나를 선택하고자 한다면 서슴없이 svn을 쓸 것 같은 이유는, svn이 가지는 단 하나의 장점 때문이다. 그것은 커밋 단위가 파일이 아니라 Repository 전체의 스냅샷(체인지셋이라고 부르는 것 같다)이라는 것이다. sv..