아는지 모르겠지만, SVN을 얻기 전에 우리 회사는 아주 오랫동안 CVS로 작업을 해왔다. 우리는 사용자나 개발자의 시점으로 CVS을 알고있다. 대략 같은 기준으로 우리는 SVN을 알게 되었다. 그리고 의심없이 다른분도 가졌을만한 의문을 공유하게 되었다. "어떤 것이 더 좋을까?"
의문을 가져도 좋은 것이, 이것이 SVN을 위한 IDE 플러그인 제작을 의뢰하는 수많은 사용자 요청으로부터 시작되었기 때문이다. 어쨌든 우리 의지는 SVN으로 작업을 시작하도록 무게를 두게 했다. 때문에 결과물은 SVN이 CVS가 가진 단점을 없앤 대체물 모양이 되었다. 불행히도, 우리가 보기에는 SVN은 CVS의 대체물이 아니고, CVS의 단점을 제거한 것도 아니었다. 더군다나, CVS에게 밀린다. 따져보면, CVS와 SVN의 C++과 자바로 비교될 수 있다. 분명히, CVS나 SVN은 소스세이프(SourceSafe)보다 강력하다. C++과 자바가 베이직(Basic)보다 강력한 것처럼. CVS는 소스 제어 시스템의 거의 모든 기능을 보여준다. 그렇다고 항상 편리하거나 기능적이지는 않다. SVN은 CVS의 일부 기능을 수정하고 확장했다. 간단히 중요한 몇몇 기능은 제외했다. 예를 들어 태그나 브랜치 중 무엇을 만드냐 정하는 건 쉽지 않은 문제이다. 그리고 당신이 편집하는 다른 파일과 구별하는데도 도움이 되지 않는다. 이 점은 자바 개발자가 해낸 점과 닮았다. 여러분이 포인터를 필요로 하지 않을 때 자바 개발자들이 나선다. 거기에는 연산자 오버로딩도 필요없다. 그리고 등등.
그러므로, 지금까지 보면 SVN은 CVS를 대신할 수 없다. SVN은 CVS와 닮은 다른 시스템이 다. 고유한 기능이 있고, 목적에 부합하는 기능을 제공한다. 이런 기능들은 특정 개발 환경에 더 적합하게 한다. 이를테면 파워빌더가 있다. 아래에서 이들 시스템의 장점과 단점을 비교한 걸 볼 수 있다. 다루지 않은 것은 두 시스템이 서로 유사하다고 판단된 것들이다. 녹색 배경은 장점이고, 핑크는 단점을 뜻한다. 선택의 갈림길에 처한다면, 둘다 써보면서 아래 설명들에 주의를 기울여보기를 권한다. 여러분은 Subversion 개발자와 Pushok 구성원간의 토론도 볼 수 있다.
주) 이 비교는 최종적인 것으로 볼 수 없다. 두 시스템은 여전히 개발중이기 때문이다. 마지막 갱신은 2005년 6월 19일에 CVS NT 2.5.01, SVN 1.2로 이뤄졌다.
| # | 비교 사항 | CVS | SVN |
|---|---|---|---|
| 1 | 보관 형태 |
CVS는 RCS라는 버전 관리 파일 형태에 기초한다. CVS에 연결된 각 파일은 일부 추가 정보를 포함한다. 분명한 점은 이들 파일의 트리 구조는 로컬 디렉토리의 트리와 동일하다. 그러므로 CVS을 사용하여 데이터 손실에 집착할 필요가 없는 동시에, 필요하다면 RCS 파일을 직접 고칠 수 있다. |
SVN 시초는 관계 데이터베이스(BerkleyDB) 혹은 이진 파일(FS_FS)의 집합이다. 그런 점에서, 여러 문제가 있고(이를테면 공유 파일 간의 동시 접근), 새로운 기능도 가능하게 한다(일례로 작업 수행을 위한 트랜잭션). 달리 보면 데이터 저장은 투명하지 않고, 결국 사용자에게 접근적이지 않다. 이 점은 회복 및 복구 기능이 제공되는 이유이기도 하다. |
| 2 | 속도 | CVS가 더 느리다. |
전체적으로 몇몇 구조적인 솔루션으로 인해, SVN은 CVS보다 꽤 빠르다. 네트워크를 통해 더 적은 정보를 전송하고 오프라인 상태에서 더 많은 작업을 지원한다. 동전의 양면과 같다. 속도 향상은 당신의 컴퓨터에 모든 작업 파일의 백업을 저장해 얻어진다. |
| 3 | 태그와 브랜치(중요!) | 우리 판단에, 적절하게 구현되었다. |
SVN 개발자는 태그와 브랜치로 작업하는 세 가지 사항을 소신있게 제거했다. 실제로 이것은 복사한 파일을 다룰 수 있다거나 변경 기록을 저장한 보관소의 디렉토리라는 두 개념을 대체한다는 걸 의미한다. 태그나 브랜치를 만드는 건 보관소에 복사하는 것으로 대체될 수 있다. SVN 개발자 시각에서, 이것은 훌륭한 결정이며, 작업을 간단하게 해주었다. 그러나, 우리는 동의하지 않는다. 브랜치만 보면, 그렇게 나쁜 건 아니다. 이제 브랜치는 없어지고 대신 보관소에는 폴더들이 나뉘어 있다. 그것들은 서로 연결 관계가 있다. 태그를 보면, 더 나쁘다. 당신은 코드를 나눌 수 없다. 이 기능은 없어졌다. 확실히, 몇몇 확장 사항은 SVN의 파일 전체에 고유한 숫자를 매겨서 얻어진다. 그래서 모든 보관소가 버전 번호를 가지나, 각 파일들은 그렇지 않다. 어쨌든 우리는 당신이 의미있는 태그 대신 4자리 숫자로 저장되는 게 그리 편하지는 않다는 걸 무시하지 않을거라 생각한다. |
| 4 | 메타 데이터 |
CVS는 단지 파일만 저장한다. |
SVN은 파일에 이름지어진 속성을 몇 개든 관계없이 덧붙이는 걸 지원한다.매우 뛰어난 기능이지만, 정말 필요한 기능인지는 판단하기 힘들다. |
| 5 | 파일 형식 |
CVS는 원래 문자 형식의 자료 보관을 위해 만들어졌다. 그리하여 서버나 클라이언트를 변경할 때 다른 파일(이진 파일, 유니코드) 저장이 구분되지 않고, 특별한 정보를 필요로 한다. |
SVN은 모든 파일 형태를 조정하며, 당신의 명령을 요구하지 않는다. |
| 6 | 롤백 |
CVS는 시간이 좀 걸리더라도 보관소에 있는 어떠한 커밋도 롤백한다(각각의 파일은 독립적으로 처리된다) |
SVN은 커밋에 대한 롤백을 지원하지 않는다. 우리 제안은 최근의 올바른 보관소 상태를 잘못된 커밋을 덮어 쓰기 위해 복사해두라는 것이다. 어쨌거나 잘못된 커밋은 보관소에 남아있다. |
| 7 | 트랜잭션 |
CVS에서 "전부 아니면 전무"라는 원칙 하의 트랜잭션 지원은 완벽하게도 없다. 예를 들어, 몇몇 파일을 체크인했을 때(서버로 파일이 전송된다), 이들 중 일부만 완료할 수 있다면, 나머지는 그렇지 않을 수도 있다(충돌 등의 이유로 인해). 규칙에 따르면, 이런 상황을 복구하고 남은 파일을 위한 작업이 반복(모든 파일이 아닌)되는 것으로 충분하다. 그래서 파일들은 두 단계로 확인되어야 한다. 이 기능의 부재로 인한 보관소가 손상된 사례는 관찰되지 않았다. |
SVN은 "전부 아니면 전무"라는 원칙 하에 트랜잭션을 지원한다. 이건 장점이 될 것 같다. |
| 8 | 유용성 |
현재 CVS는 당신이 필요한 어디든지 지원된다. |
SVN은 아직 널리 쓰이지 않으며, 그 결과 지원되지 않는 곳도 있다. |
| 9 | 내부 구조 및 코드 |
CVS는 매우 오래된 시스템이다. 내부적으로 CVS는 RCS를 실행하는 스크립트 모음이다. 나중에 이것은 하나의 실행 파일로 모아졌다. 허나 코드의 내부 구조는 빈약하고 역사적으로 많은 수정을 거쳐왔다. 지금까지 처음부터 CVS를 다시 작성하려는 시도가 몇번 있었으나, 성공 사례는 알려지지 않았다. 우리는 개인적으로 클라이언트 코드를 풀어서 플러그인과 CVS간에 더 높은 결합도를 얻어보려 했으나 성공하지 못했다. 이제 우리는 CVS의 기능이 앞으로 더 향상되리라 생각하지 않는다. |
서브버전 제작자는 내부 SVN 설계에 많은 시간을 들였다. 아직 그들이 내린 결정이 얼마나 좋을지는 모른다. 그러나 분명한 건 코드가 매우 확장성있고, 더 나은 향상이 오고 있다는 점이다. |
| 총점 |
4 |
5 |
이 글은 스프링노트에서 작성되었습니다.
