CVS, SVN, VSS 장단점 비교, 차이점, 사용 후 느낀점

****************************
 작성일: 2009.03.19(목)    
 작성자: Myung-Ju.Kim      
 블로그: imover.tistory.com
****************************

1. CVS와 SVN의 차이점을 정리한 테이블

구분	CVS	SVN
커밋단위	파일	체인지 셋(change set)
원자적 커밋(커밋 실패 시 롤백)	미지원	지원
처리 속도	느림	빠름
파일과 디렉토리의 삭제, 이동, 이름변경, 복사	미지원	지원
소스코드외 이진파일(문서, 라이브러리 등) 지원	미지원	지원
GUI(Graphic User Interface) 지원여부	지원	지원
웹인터페이스(Web Interface) 지원여부	지원	지원

2. CVS, SVN을 포함한 기타 버전 관리 도구들에 대한 간단한 설명 및 장단점 비교 테이블

구분	설명	장점	단점
VSS	VSS는 'Visual SourceSafe'의 약자로써 버전관리 소프트웨어 이다. One Tree Software라는 회사에 의해 16비트용 응용프로그램(ver 3.1)으로 처음 만들어 졌다. 그 시절 MicroSoft에도 'Delta'라는 이름의 버전관리 소프트웨어가 있었으나, 그 기능과 성능이 VSS만 못했으므로 1994년 MicroSoft는 One Tree Software를 인수하여 1995년 32비트용 응용프로그램의 첫 버전인 VSS 4.0을 출시한다. 가장 최근 버전으로는 Visual SourceSafe 2005가 있다.	1. MicroSoft사의 제품이기 때문에 'Microsoft Visual Studio'를 포함한 기타 MicroSoft사의 솔루션들과의 통합이 아주 용이하다. 2. Windows기반이기 때문에 설치와 사용이 그다지 어렵지 않다. 3. 동시 수정이 불가능 하여 작업의 충돌이 일어나지 않는다. (※ 단점이기도 함)	1. VSS의 직접적인 파일기반 접근 메카니즘은 어떤 클라이어트든 저장소안의 파일을 잠금(locking)후에 수정하는 것을 허락하기 때문에 만약 파일을 업데이트 하는 도중 클라이언트의 PC에 충돌이 일어나기 라도 하면 파일이 손상된 상태로 남겨질 수 있다. (잦은 저장소 손상) 2. 파일이 누군가에 의해 수정중인(locking) 경우 파일에 접근하지 못함. (동시 수정 불가능) 3. 대규모 프로젝트에는 부적합 하며, 소규모(5명) 프로젝트인 경우에 적합하다. (대규모 프로젝트에는 MicroSoft사의 'Team Foundation Server' 사용) 4. 가지치기(branch) 기능이 빈약하다.
CVS	CVS는 'Concurrent Versions System'의 약자로써 버전관리 소프트웨어 이다. 소프트웨어 개발 프로젝트에서 파일 단위의 모든 작업과 모든 변화를 추적하고 여러 개발자(지역적으로 떨어진)가 협력하여 작업할 수 있도록 지원한다. CVS는 GNU 라이선스 하에서 배포되며 오픈 소스 프로젝트에서 널리 사용된다. 현재는 설계상 몇가지 크고 작은 문제들로 인해 Subversion(SVN)에게 그 자리를 내어주고 있는 추세이다.	1. CVS는 오랜기간에 걸쳐 많은 사용자들을 확보한 안정되고 검증된 버전관리 소프트웨어 이다. 2. 하나의 파일에 대한 동시작업이 가능하다. 3. 병합(merge), 가지치기(branch), 태그(tag), 비교(compare) 기능을 지원한다. 4. Unix, Linux, Windows 등 대부분의 운영체제를 지원한다. 5. 파일 전체를 저장하는 것이 아니라 변경사항만을 저장함으로 백업용량을 적게 차지한다.	1. CVS 저장소의 파일들은 이름을 바꿀 수 없다. 제거하고 나서 다시 추가해야 한다. 2. CVS 프로토콜은 디렉터리의 이동이나 이름변경을 허용하지 않는다. 서브 디렉터리의 파일은 모두 지우고 다시 추가해야 한다. 3. 아스키 코드로 된 파일 이름이 아닌 유니코드 파일을 제한적으로 지원한다. 4. 속도가 느리다. 6. 커밋 실패 시 롤백이 지원되지 않는다. 7. VSS와 비교했을 경우 저장소가 다소 지저분 하다. ('CVS' 디렉토리들로 인해)
SVN	SVN은 'Subversion'의 약자로써 버전관리 소프트웨어 이다. 명령행 인터페이스에서 사용하는 명령어를 따서 'SVN'이라고 줄여서 부르기도 하며, CVS의 단점을 보완하기 위해 만들어 졌다.	1. 원자적 커밋을 지원하므로 다른 사용자의 커밋과 엉키지 않으며, 실패 시 롤백 기능을 지원한다. 2. 파일과 디렉토리의 삭제, 이동, 이름변경, 복사등을 지원한다. 3. 소스파일 이외에 이진파일도 효율적으로 저장할 수 있다. 4. 디렉터리도 버전 관리를 할 수 있다. 디렉터리 전체를 빠르게 옮기거나 복사할 수 있으며, 리비전 기록도 그대로 유지한다. 5. 저장소의 크기에 상관 없이 일정한 시간 안에 가지치기나 테그를 할 수 있다. 6. 처리 속도가 빠르다.	1. 안정성에 있어선 아직까진 CVS에 미치지 못함. (이제 막 사용량이 증가하고 있는 추세) 2. VSS와 비교했을 경우 저장소가 다소 지저분 하다. ('.svn' 디렉토리들로 인해) 3. 잦은 커밋으로 인해 리비전 번호의 인플레이션(inflation)이 유발될 수 있다. 4. 소스코드는 Diff를 통해 병합(Merge)이 가능하지만 이진파일은 어느 한쪽을 버릴 수 밖에 없다.

3. TortoiseSVN을 사용하면서 느낀 점이나 생각에 대해 자유롭게 정리

Java 응용 프로그램 개발을 담당하고 있는 저는 지금까지 약 4년간 총 2곳의 회사에서 버전 관리 소프트웨어로 CVS만을 사용하여 왔습니다. 우연치 않게 이번 기회에 주어진 토론에 참여하기 위해 처음으로 TortoiseSVN(이하 'SVN'으로 하겠습니다.)을 설치해서 사용해 보았는데, SVN에서 장점으로 내세운 사항들이 지금까지 줄곧 사용해온 CVS와 비교해서 실질적으로 얼마나 많은 성능 개선과 기능 향상이 있었는지를 비교해 보고 그에 대한 제 생각들을 적어 보겠습니다.

원자적커밋(atomic commit)
우선 SVN의 큰 장점 중에 하나인 '원자적커밋(atomic commit)'에 대한 제 의견을 말씀 드리겠습니다. SVN은 커밋의 단위를 파일로 하는 CVS와 달리 '체인지 셋(change set)'을 커밋의 단위로 하기 때문에 원자적커밋이 가능 합니다. (SVN은 커밋 실패 시에 롤백(rollback)이 보장 됩니다.)
이에 반해 CVS는 앞서 말한 것처럼 파일 단위로 커밋을 처리하기 때문에 커밋 시도 중 실패하게 되면 이미 커밋 되어버린 내용들은 롤백이 되지 않는 상황이 발생 합니다. 따라서 이러한 점을 CVS의 문제점으로 지적 할 수 있지만, 제가 경험한 바에 의하면 CVS가 파일 단위의 커밋을 이용한다는 이유로 심각한 문제가 발생한 경우는 아직까지 보지 못했습니다. (만약 그랬다면 CVS가 지금까지 수많은 레퍼런스를 남기며 사용되어 오지 못했을 거라 생각됩니다.) 그러한 이유는 실제 개발과 운영 시에는 수많은 파일과 디렉터리를 포함하고 있는 용량이 큰 디렉터리 전체에 대한 커밋을 시도하는 경우는 거의 발생하지 않고 대부분 발생하는 커밋, 업데이트(update), 롤백 등의 작업이 파일 단위로 일어나기 때문 입니다. 그리고 혹시 이러한 경우가 발생하게 된다고 할지라도 대부분의 사용자들은 안전장치로 원본을 백업 후에 커밋을 시도하는 자체의 룰(rule)을 정해 따르고 있기 때문에 커밋 이전에 이러한 룰만 충실이 지키더라도 롤백이 안됨으로 인해 발생할 수 있는 심각한 문제는 사전에 예방할 수 있기 때문 입니다.
사용자가 커밋을 실행 한다는 뜻은 단순히 변경된 소스코드를 적용한다는 것 이외에도 변경 사항에 대해 충분한 테스트와 검증을 마친 상태라는 의미가 함께 포함 되어 있다고 생각 합니다. 따라서 커밋은 신중해야 합니다. SVN의 경우 사용자가 커밋 시도 중 실패하게 되면 자동으로 롤백을 지원하니 큰 문제가 없을 것이라 생각하고 사용자들이 신중하지 않게 커밋을 남발하는 상황이 발생할 수도 있고 그로 인해 저장소 안에 여러 가지 문제들이 발생할 수도 있습니다. 장점이 단점으로 작용할 수도 있다는게 제 생각합니다. SVN이 커밋 단위를 체인지 셋으로 하여 CVS에 비해 처리 속도를 크게 향상 시킨 것은 정말 큰 장점이라고 봅니다. 하지만, 처리 속도 향상이 아닌 원자적커밋의 지원 때문에 현재 사용하고 있는 CVS를 SVN으로 전향하는 것은 좀더 고려해 봐야 할것 같습니다.

 

파일과 디렉터리의 이동, 이름변경, 삭제, 복사의 지원
SVN에서는 파일과 디렉터리의 이동, 이름변경, 삭제, 복사를 지원 합니다. 저의 경우 회사에서 새로운 라이브러리를 작성해야 할 때마다 CVS 저장소에 새로운 이름으로 JAVA 프로젝트를 하나 생성하고 작업을 시작하게 되는데, 작업을 진행하다 보면 클래스파일 또는 디렉터리의 이름을 변경한다거나 위치를 옮기고 싶은 경우가 종종 발생 합니다. 이러한 경우 SVN에서만 제공하는 이 기능들은 CVS와 비교했을 경우 분명 많은 도움이 된다고 생각 합니다.
다만 누군가가 SVN에서는 파일과 디렉터리의 이동, 이름변경, 삭제, 복사가 지원된다는 사실을 알고 SVN 명령을 이용하지 않고 일반적인 OS의 명령을 이용하여 파일과 디렉터리에 대해 이동, 이름변경, 삭제, 복사등의 명령을 실행하고 커밋을 하게되는 상황이 발생한다면 저장소에 문제가 발생할 수 있습니다. 물론 이러한 일이 발생하더라도 커밋 이전의 리비전(revision)으로 업데이트를 받으면 문제를 해결할 수도 있지만, 이런 상황이 발생하기 이전에 SVN에서 문제를 미리 감지하고 커밋을 제한하는 기능이 추가 된다면 좋을 것 같습니다.

 

바이너리파일(문서, 라이브러지) 지원
CVS에서 지원되지 않는 바이너리 파일에 대한 지원은 큰 장점이라고 생각합니다. 다만 텍스트 기반이 아닌 바이너리파일에서 충돌(conflict)이 발생 할 경우에는 둘 중 한쪽은 버려야 한다는 점은 미리 숙지하고 사용해야 할 것 같습니다.

 

충돌(conflict)문제의 해결
CVS와 비교해서 큰 차이점을 느끼지 못하였습니다. Diff를 통해 비교 후 병합(merge)한 후 커밋하는 방법은 비슷하다 생각 됩니다. 저 같은 경우에는 충돌이 발생하였을 때 병합보다는 해당 사용자와의 협의를 통해 파일을 수정한 후 그 파일로 커밋을 하여 문제를 해결 하는 방법을 주로 사용 합니다.

 

사용법
TortoiseSVN과 SVN Eclipse plug-in을 설치해서 사용해 본 결과 사용법에선 CVS와 큰 차이점 없이 비슷하여서 저와 같이 CVS에 익숙한 사용자라면 누구나 어려움 없이 사용할 수 있으리라고 생각 합니다.

 

기타
제 개인적인 생각으로는 얼마 후면 일정관리, 소스코드개발, 문서작성을 포함한 기타 프로젝트와 관련된 모든 업무가 '서비스로서의 소프트웨어(SaaS)'로써 웹(WEB)을 기반으로 이루어 지는 시대가 도래할 것이라고 생각 됩니다. 따라서 SVN과 함께 Trac의 설치를 한번 진행해 보고 웹을 통해 버전관리가 어떻게 이루어지는지 또 거기에 개선할 사항은 없는지에 대해서 한번쯤 살펴 보는것도 좋을것 같습니다.

이상으로 TortoiseSVN을 사용해 본 후 느낀 제 생각에 대한 정리를 마칩니다. 부족한 글 읽어 주셔서 감사드리고, 위 내용은 지극히 제 개인적인 소견 이란것을 염두해 두셨으면 감사 하겠습니다.