머샤의 인생과 웃기는 고양이

가끔 바라보는 블로그 유입경로에 CVS나 SVN의 Lock기능을 검색해서 오시는 구글러 분들이 계십니다.

거기다가, 컨설팅을 진행하는 사이트 혹은 문의하시는 고객분들 중에도 CVS는 Lock을 사용 할 수 없어 않되요..라고 말씀하시는 고객분들도 계시고요.

이글은 이파피루스 대표이신 모던보이님의 글에 트랙백하기 위해서 씁니다.

이파피루스 대표께서 운영하는 블로그에 "버전관리시스템과 포스트모더니즘"이라는 글이 올라왔습니다. 물론 글의 내용은 본인도 상당히 공감하는 통제와 자유화의 관점에서 느끼는 소견이라 사족을 달고 싶지는 않습니다. (동감한다고 해야 할까요?)

하지만, CVS와 SourceSafe의 비교에서 일반 사용자(버전관리 시스템을 개발하는 사람은 아닌)분들이 조금 헷갈려 하시는 부분이 있어 언급하고자 합니다.

CVS와 SourceSafe로 대표되는 개인용 버전관리시스템의 가장 큰 차이점은 "무결성"을 유지하는 방법입니다.
여기에서 무결성이란, 현재 수정중인 소스를 여러 사람이 한꺼번에 수정 했을때, 혹은 이전 버전을 등록하려고 하는 등의 사용자의 실수를 방지하고, "버전관리 시스템"차원에서 결함이 없을을 보장하는 것 입니다.

크게 두가지 방법이 있습니다.
Lock-Modify-Unlock 방식과 Update-Modify-Commit 방식이 있습니다.

이해하기 쉽게 Lock방식은 "내가 수정 하는 동안 다른 사람은 아무도 수정하지 못한다."입니다. 이 방식으로 사용하는 버전관리 도구는 SourceSafe, PVCS가 대표적입니다만, SourceSafe는 2005 이후로 공식적으로는 Update방식을 지원하는 것으로 되어 있습니다. :)

Update방식은 "수정하기 전에 내 소스를 최신버전으로 맞추고(Update) 수정을 완료 한 다음에 반영(Commit)할 때, 내가 수정하는 동안 다른 사람이 수정 했는지 확인하고 반영한다."입니다.

여기에서 중요한 점은 수정하기 전에 반드시 Update해서 최신버전으로 맞추어야 잘 작동한다는 것으로, Lock방식에 익숙한 사용자분들이 많이 어려워 하는 부분이기도 합니다. 미리 미리 Update하지 않면 충돌(Conflict)의 원인이 되고, 그 충돌을 해결하는 과정에서 (이게 쓸만하네, 못쓰겠네, 소스를 날려 먹었네, 등등 여러 상황이 연출 됩니다.)

여기에서 일반 사용자분들이 생각하지 못하는 핵심은.
"Lock 방식이 우수하거나, Update 방식이 우수한 것이 아니라. 작업영역(소스를 체크아웃 받는 영역)이 공용으로 사용하는 폴더인지, 사용(개인)폴더 인지에 따라 더 적합한 방식이 결정되는 것입니다."

Update방식은 개인 작업영역을 고려하여 만들어진 방식입니다.
(쉽게) 우리나라 전산실에서 주로 하는 형태인 개발용 Unix Server에서 공용ID 하나로 개발하는 환경에서 Update방식을 지원하는 CVS를 사용하는 것은 (않되는 것은 아니겠지만) 상당히 난해 할 수 있습니다.

반면에 Lock방식인 SourceSafe나 PVCS는 몇십 혹은 몇백명의 개발자들이 투입되는 대형 SI프로젝트에서는 병렬개발 혹은 개발 퍼포먼스에 많은 문제가 발생합니다.라이브러리 등에서 대기하거나, Lock잡고 풀어주는것을 잊어 버리거나 Lock을 모니터링 하기 위해서 Scan하는 시간이 너무나 길어지는(가장 일반적인 어려움 입니다.) 현상이 발생 합니다.

여담이지만, SourceSafe나 PVCS는 Desktop용으로 설계된 제품이기 때문에, 일정 규모이상의 사용자가 사용하는 것은 당연히 무리가 있습니다. 10명 정도의 팀이 사용하기에는 비용대비 무난한 솔루션이지만 30명 혹은 100명이 사용한다면 다른 관점에서 접근하는 것이 좋습니다.

결론적으로 CVS방식 혹은 SourceSafe방식. 어떤 방식으로 버전을 관리 할 것인지 결정하는 핵심은 작업영역의 공용/사용 여부와 사용방식의 차이입니다. 어떤 솔루션이 더 우월(우수)해서 그런것은 아닐 것입니다.

그런 관점에서 CVS가 모더니즘적인 느낌이라는것은 저도 100% 공감하는 바입니다. :)
(하지만 시대의 흐름에 따라 도구의 기능은 자꾸만 변해하는 것이겠지요. 받아들이고, 만들어 내고...)

우리팀이 만들고 있는 실루엣의 경우에는 1.x 버전에서는 Lock방식으을 지원 했지만, 2.x에서는 Update방식중 일부를 포함해서 함께 지원하고 있습니다. CVS처럼 완전 Auto Merge를 지원하지는 않지만, 개별 소스의 변경 혹은 Merge 필요여부 상태를 알려주고, 사용자가 필터링해서 작업 할 수 있도록 하고 있습니다. 한국 개발자들의 눈높이에 맞춘기능이라고 할까요 :)

 

Project Version Manager Demo

---

전통적인 버전관리툴들, 그것이 Lock 중심의 것들(PVCS, SourceSafe...)이던지, Update 중심의 것들(CVS...) 이던지 상관없이 파일 중심의 버전관리 도구들입니다.

즉, 하나의 파일에 대한 버전변경을 추적하는 기능을 가지고 있는 것이지요.

실제 개발팀에서는 파일 하나의 버전에 대한 추적도 중요하지만, 변경셋(Change Set)에 대한 이력을 추적하고 관리하는 것이 무엇보다도 중요합니다.

CVS를 대체하겠다고 만든 SVN은 그런 의미에서 뉴트랜드에 부합하는 버전관리도구라고 할 만합니다.

몇몇 외산 버전관리 도구들이 Snap Shot이름으로 그 변경내용을 저장하는 방법을 제공 하기는 합니다만, 자동으로 저장되는 것이 아니라 사용자가 필요시점에 Snap을 작성하는 것이라 불편한 점이 많았습니다.

사용자가 일일이 snap을 작성하는 부분은 일견 "레이블" 기능과도 닮아 있습니다만, 사용방법과 Scope가 다릅니다. (그 이야기는 나중에 기회가 있으면...)

상단에 링크된 실루엣 프로젝트 버전 관리를 유심히 살펴보면 각 변경내역을 기록하고 추적하는 다양한 기능이 구현된 것을 볼 수 있습니다.
중요 기능을 정리하면

• Check In 시점에 자동으로 Project Revision 생성
• Project간 Revision Compare (Branch된 다른 Project에 대해서 Compare)
• 특정 Project 리비전에 Check In된 소스 조회 및 복원
• 특정 Project 리비전 복원 (프로젝트 내용 전체를 복원하는 기능)

형상관리, 버전관리는 도구도 중요합니다만, 개발팀이 얼마나 의욕을 가지고 꾸준히 실천하느냐가 무엇보다 중요합니다.
그 실천의 과정에서 필요한 도구는 자연스럽게 방법이 찾아지고, 정착 될 것입니다.