"CVS에서 Subversion으로 바꾸기, 좋을까(http://cwryu.tistory.com/17)"라는 글이 많은 사람들에게 인용되고 있고 마치 전문가의 글인것 처럼 전달되면서 편협된 정보를 전달할 우려가 있어, 제가 이에 대한 반박을 하고자 합니다.


바꾸어 말하면 안정된 프로젝트까지 가기에는 여러가지 바뀔게 많다는 소리인데, 이런 상황에서는 어쩌란 말인지? 거기다 오타가 섞인 이름을 끝내 바꾸지 못했다는 것을 당연하다는 듯이 이야기 하는 것도 정말 어처구니가 없습니다.

버전 관리 시스템을 사용한다는 것은 잘못된 것은 수정하고 그 기록을 남기기 위해서 사용하는 것입니다. CVS에서 이름 바꾸기가 잘 되지 않는다고 잘못된 것을 방치하는 것은 주객이 전도된 상황이 아닌가요?

이 주장은 단점도 아닌데(아주 당연한 기능인데) 단점을 만들기 위해 근거를 끼워 맞춘것에 불과합니다.


문제가 될 상황이 별로 많지 않다는 것은 한번이라도 문제가 생길 수 있다는 소리이며, 커밋과 태깅을 하다가 중간에 짤리면 그것을 수정하기 위해 엄청난 시간과 노력이 소비된다는 것을 알아야 합니다.

Subversion은 커밋과 태깅이 atomic 해서 이런 문제가 전혀 발생하지 않으므로 여기에 소비되는 시간과 노력을 절약할 수 있습니다.

논리적 충돌은 곧 버그를 의미하며 이것을 안고치면 계속 버그로 남아있을 텐데 당연히 신경을 쓸 수 밖에 없습니다. 그리고 이런 이유로 atomic 커밋이 별 장점이 되지 않는다고 주장하는 것은 문제의 핵심을 벗어난 것입니다.

atomic 커밋, 태깅의 핵심은 이것을 지원하지 않음으로 인해서 생기는 문제가 어떤 것이냐는 것입니다.


알기 어려우면 왜 적었는지 모르겠습니다. 제가 다시 설명하자면, Subversion은 태깅 및 브랜칭을 할 때 내부적으로 링크만 생성하는 것이기 때문에 서버측의 로드는 거의 제로에 까깝습니다.


서버가 멀리있는 사람 뿐만 아니라 내부 네트워크에서도 이런 차이가 쾌적한 개발 환경을 제공해 준다는것을 간과하고 있습니다.


쓰는 사람 입장에서 CVS가 불편하다면 닫힌 프로젝트라도 바꾸는 것이 당연하고, 얻는 장점도 별로 없는 것이 아니라, 인용글에서 제시한 1, 2, 3, 4번의 장점을  장점을 모두 얻을 수 있는데, 뭔 장점이 별로 없다는 것인지 모르겠습니다.

저는 CVS에서 Subversion 전환을 강요할 목적은 전혀 없습니다. 하지만 잘못된 정보가 전달되는 것을 막기 위해 이렇게 글을 썻음을 다시 한번 알려드립니다.