"CVS에서 Subversion으로 바꾸기, 좋을까(http://cwryu.tistory.com/17)"라는 글이 많은 사람들에게 인용되고 있고 마치 전문가의 글인것 처럼 전달되면서 편협된 정보를 전달할 우려가 있어, 제가 이에 대한 반박을 하고자 합니다.
바꾸어 말하면 안정된 프로젝트까지 가기에는 여러가지 바뀔게 많다는 소리인데, 이런 상황에서는 어쩌란 말인지? 거기다 오타가 섞인 이름을 끝내 바꾸지 못했다는 것을 당연하다는 듯이 이야기 하는 것도 정말 어처구니가 없습니다.
버전 관리 시스템을 사용한다는 것은 잘못된 것은 수정하고 그 기록을 남기기 위해서 사용하는 것입니다. CVS에서 이름 바꾸기가 잘 되지 않는다고 잘못된 것을 방치하는 것은 주객이 전도된 상황이 아닌가요?
이 주장은 단점도 아닌데(아주 당연한 기능인데) 단점을 만들기 위해 근거를 끼워 맞춘것에 불과합니다.
문제가 될 상황이 별로 많지 않다는 것은 한번이라도 문제가 생길 수 있다는 소리이며, 커밋과 태깅을 하다가 중간에 짤리면 그것을 수정하기 위해 엄청난 시간과 노력이 소비된다는 것을 알아야 합니다.
Subversion은 커밋과 태깅이 atomic 해서 이런 문제가 전혀 발생하지 않으므로 여기에 소비되는 시간과 노력을 절약할 수 있습니다.
논리적 충돌은 곧 버그를 의미하며 이것을 안고치면 계속 버그로 남아있을 텐데 당연히 신경을 쓸 수 밖에 없습니다. 그리고 이런 이유로 atomic 커밋이 별 장점이 되지 않는다고 주장하는 것은 문제의 핵심을 벗어난 것입니다.
atomic 커밋, 태깅의 핵심은 이것을 지원하지 않음으로 인해서 생기는 문제가 어떤 것이냐는 것입니다.
알기 어려우면 왜 적었는지 모르겠습니다. 제가 다시 설명하자면, Subversion은 태깅 및 브랜칭을 할 때 내부적으로 링크만 생성하는 것이기 때문에 서버측의 로드는 거의 제로에 까깝습니다.
서버가 멀리있는 사람 뿐만 아니라 내부 네트워크에서도 이런 차이가 쾌적한 개발 환경을 제공해 준다는것을 간과하고 있습니다.
쓰는 사람 입장에서 CVS가 불편하다면 닫힌 프로젝트라도 바꾸는 것이 당연하고, 얻는 장점도 별로 없는 것이 아니라, 인용글에서 제시한 1, 2, 3, 4번의 장점을 장점을 모두 얻을 수 있는데, 뭔 장점이 별로 없다는 것인지 모르겠습니다.
저는 CVS에서 Subversion 전환을 강요할 목적은 전혀 없습니다. 하지만 잘못된 정보가 전달되는 것을 막기 위해 이렇게 글을 썻음을 다시 한번 알려드립니다.
그놈 CVS가 subversion으로 전환한 이후 얼마가 지났으나 사실 큰 장점을 못 느끼는 게 사실이다. 애초에 subversion은 cvs와 같은 모델의 vc를 만들면서 cvs의 단점을 보완하는 게 목적이었고, 사용법부터 시작해서 크게 다르지 않다. 흔히 cvs와 비교해 장점이라고 하는 것들을 살펴보면:
1. renaming, file property 따위의 versioning
안정된 프로젝트일 수록 디렉토리 이름을 바꾸는 일은 그리 많지 않다. (과거에 회사에서 오타가 섞인 이름마저 끝내 바꾸지 못했던 기억이 있다.)
안정된 프로젝트일 수록 디렉토리 이름을 바꾸는 일은 그리 많지 않다. (과거에 회사에서 오타가 섞인 이름마저 끝내 바꾸지 못했던 기억이 있다.)
바꾸어 말하면 안정된 프로젝트까지 가기에는 여러가지 바뀔게 많다는 소리인데, 이런 상황에서는 어쩌란 말인지? 거기다 오타가 섞인 이름을 끝내 바꾸지 못했다는 것을 당연하다는 듯이 이야기 하는 것도 정말 어처구니가 없습니다.
버전 관리 시스템을 사용한다는 것은 잘못된 것은 수정하고 그 기록을 남기기 위해서 사용하는 것입니다. CVS에서 이름 바꾸기가 잘 되지 않는다고 잘못된 것을 방치하는 것은 주객이 전도된 상황이 아닌가요?
이 주장은 단점도 아닌데(아주 당연한 기능인데) 단점을 만들기 위해 근거를 끼워 맞춘것에 불과합니다.
2. atomic commit/tag
CVS의 commit/tag가 atomic이 아니라고 해서 문제가 될 상황도 별로 많지 않다. 오히려 (사람이 직접 신경 쓰지 않으면 해결할 방법이 없는) 논리적인 충돌이 더 많이 발생한다.
CVS의 commit/tag가 atomic이 아니라고 해서 문제가 될 상황도 별로 많지 않다. 오히려 (사람이 직접 신경 쓰지 않으면 해결할 방법이 없는) 논리적인 충돌이 더 많이 발생한다.
문제가 될 상황이 별로 많지 않다는 것은 한번이라도 문제가 생길 수 있다는 소리이며, 커밋과 태깅을 하다가 중간에 짤리면 그것을 수정하기 위해 엄청난 시간과 노력이 소비된다는 것을 알아야 합니다.
Subversion은 커밋과 태깅이 atomic 해서 이런 문제가 전혀 발생하지 않으므로 여기에 소비되는 시간과 노력을 절약할 수 있습니다.
논리적 충돌은 곧 버그를 의미하며 이것을 안고치면 계속 버그로 남아있을 텐데 당연히 신경을 쓸 수 밖에 없습니다. 그리고 이런 이유로 atomic 커밋이 별 장점이 되지 않는다고 주장하는 것은 문제의 핵심을 벗어난 것입니다.
atomic 커밋, 태깅의 핵심은 이것을 지원하지 않음으로 인해서 생기는 문제가 어떤 것이냐는 것입니다.
3. lightweight branching
이 부분은 서버의 로드와 관련된 것이므로, 알기 어렵다. 분명히 장점이다.
이 부분은 서버의 로드와 관련된 것이므로, 알기 어렵다. 분명히 장점이다.
알기 어려우면 왜 적었는지 모르겠습니다. 제가 다시 설명하자면, Subversion은 태깅 및 브랜칭을 할 때 내부적으로 링크만 생성하는 것이기 때문에 서버측의 로드는 거의 제로에 까깝습니다.
4. diff/revert에 네트워크 연결이 필요없다
이것만은 확실히 좋다는 걸 느낀다. cvs는 diff를 할 때마다 해당 파일의 전체 내용을 전송받는데, 유럽에 있는 gnome cvs 서버에서 이 내용을 받는 건 만만치 않은 일이다. 심심풀이 해커도 그리 느끼는데 업으로 삼는 사람들은 더더욱 좋다고 생각할 듯.
이것만은 확실히 좋다는 걸 느낀다. cvs는 diff를 할 때마다 해당 파일의 전체 내용을 전송받는데, 유럽에 있는 gnome cvs 서버에서 이 내용을 받는 건 만만치 않은 일이다. 심심풀이 해커도 그리 느끼는데 업으로 삼는 사람들은 더더욱 좋다고 생각할 듯.
서버가 멀리있는 사람 뿐만 아니라 내부 네트워크에서도 이런 차이가 쾌적한 개발 환경을 제공해 준다는것을 간과하고 있습니다.
subversion은 cvs와 비교해 분명한 장점이 있으나 멀쩡히 안정적으로 잘 돌아가는 닫힌 프로젝트의 vcs를 cvs에서 svn으로 바꾸는 일은 별로 추천하지 못하겠다. 옮겨가는 데 별로 무리도 없지만 얻는 장점도 별로 없기 때문이다. (gnome처럼 vcs 이용자가 워낙 많고 세계 여기저기에 퍼져 있는 경우라면 위의 3/4 항목으로 큰 이득을 볼 수도 있겠지만)
쓰는 사람 입장에서 CVS가 불편하다면 닫힌 프로젝트라도 바꾸는 것이 당연하고, 얻는 장점도 별로 없는 것이 아니라, 인용글에서 제시한 1, 2, 3, 4번의 장점을 장점을 모두 얻을 수 있는데, 뭔 장점이 별로 없다는 것인지 모르겠습니다.
저는 CVS에서 Subversion 전환을 강요할 목적은 전혀 없습니다. 하지만 잘못된 정보가 전달되는 것을 막기 위해 이렇게 글을 썻음을 다시 한번 알려드립니다.
댓글을 달아 주세요
관리자만 볼 수 있는 댓글입니다.
글이 말하는 건 svn이 그러한 장점들이 있다고는 하지만 멀쩡히 잘 쓰고 있는 CVS를 svn으로 옮겨갈 만큼의 장점은 아니라는 얘기죠. 그래서 1에서 안정된 프로젝트에서는...이라고 한 거구요.
충분히 옮겨가고도 남는 장점이라고 생각됩니다만...
글 잘봤습니다.
잘 봤습니다. CVS에서 SVN으로 옮기고 평상시 좋았던건 속도가 빠르다 였고, 특정상황에서 좋다고 느꼈던건 atomic commit/tag이 지원되었던 점이었습니다. 소스를 10개쯤 수정하고 commit했는데 멀쩡히 돌던 서버가 돌아가지 않을때....CVS에서는 좀 막막했습니다. 하지만, SVN에서는 방금 commit 한 소스만 골라서 rollback이 가능하다는 점이 참 좋더군요.
올초까지 CVS를 쓰다가 회사를 옮기고 SVN으로 프로젝트를 했는데요...
작은 차이가 실제로는 대단히 유용하며 편리하게 다가왔습니다.
물론 SVN도 아쉬운점이 없는건 아니지만 CVS는 비할바가 못되는것 같습니다.