Life Algorithm

작년까지는 Subversion을 썼는데 svncommand 없이 어떻게 사용했나 싶었는데...
올해 회사를 옮기면서 CVS를 쓰게 되고, 불편해 하면서 그냥 쓰다가(그냥 CVS와 SVN만 놓고 봐도... 아무리 생각해도 SVN이 편합니다 -_-) 문득 생각이 나서 뒤져 봤더니 cvscommand도 있더군요.

이것들이 무엇이냐..하면, vim으로 개발하시면서 CVS 및 SVN을 쓰시는 분들께 매우 유용한 vim 플러그인입니다.
vim을 빠져 나가지 않고 각종 CVS 커맨드를 쓸 수 있어서 매우 편하고 매력적입니다. 그리고 log나 diff, annotate등을 vim의 syntax highlighting으로 볼 수 있으니 가독성도 훨씬 좋지요.

일단 다운로드는 아래에서...
svncommand : http://www.vim.org/scripts/script.php?script_id=922
cvscommand : http://www.vim.org/scripts/script.php?script_id=90

cvscommand는 현재 vcscommand로 프로젝트 명이 바뀌어서 CVS, SVN, GIT, SVK를 통합 지원하는 프로젝트로 바뀌었네요. CVS만 쓰실 분들은 저~ 아래쪽의 1.76 버전 cvscommand.zip을 받으시면 됩니다. 그리고 vcscommand는 vim 7.0이상만 지원합니다.

cvscommand의 경우 CVS[명령어]의 형태로 사용하면 됩니다. Subversion 쪽도 거의 같습니다.
몇 가지만 예를 들면,

:CVSAdd - cvs add
:CVSAnnotate - cvs annotate
:CVSCommit - cvs commit

등등입니다. 웬만한 건 거의 다 있으며 CVS에 없는 명령만 몇 가지 소개하겠습니다.

:CVSVimDiff - diff를 vimdiff 형태로 보여줍니다. CVSDiff도 있지만 적응되면 이 쪽을 더 자주 쓰게 될겁니다.
:CVSRevert - CVS에는 없지만 svn revert와 동일합니다. 수정 사항을 저장소의 내용으로 되돌립니다(파일을 삭제하고 다시 update 받습니다).
:CVSGotoOriginal - log, diff등을 보다가 원래 파일로 되돌아갈 때 씁니다.

꽤 편하니 vim으로 개발한다면 꼭 써보시기 바랍니다.

참, 설치는 /usr/share 밑의 vim 디렉토리를 찾아서(저같은 경우 /usr/share/vim/vim63/) plugin 디렉토리와 syntax 디렉토리에 맞게 넣어주고, svncommand의 경우 ~/.vimrc를 약간 고치면 됩니다. 각 .vim 스크립트를 열어보면 알 수 있긴 합니다만...

au BufNewFile,BufRead  svn-log.* setf svnlog
au BufNewFile,BufRead  svn-commit.* setf svn

위 두 줄을 추가해 주시면 됩니다.

이올린에 북마크하기(0) 이올린에 추천하기(0)

제목을 잘 하지도 못하는 영어로 써서 죄송합니다 -_-

SCM은... 쉽게 말하면 버전 관리라고들 하죠. Source Configuration Management의 약자입니다.
CVS, Subversion같은 거요. 아니면 비주얼 소스 세이프라든가... 돈 많은 회사면 Clear Case 쓸 수도 있고...
이런 거 안 쓰세요? 쓰자고 건의하세요, 힘들어 죽어버릴 거 같다고...ㅡㅡ; 못 쓰겠대요? 옮기세요... 그 회사엔 붙어 있어도 좋은 꼴 못 봅니다 -_-;

CVS든 SVN이든 여기저기 많이 쓰긴 하지만, 기본적인 SCM의 기능들이랄까 그 개념은 잘 모르고 쓰는 경우가 많은 것 같습니다.
프로그래밍 언어, 자료구조, 알고리즘 등은 학교에서 가르치지만 막상 이런 실용적인 것들은 가르치지 않지요. GDB나 CVS 처음 써보고 무척 감탄했던 기억이 나는군요. '세상에 이런 것도 있었구나'하는 느낌...? -_-

SCM 툴도 기본적인 원리나 개념들은 관련 S/W들이 오랜동안 개발되고 숙성되어 오면서 충분히 정립된 상태라고 볼 수 있을 것 같습니다. 그런 것들에 대해 쓰는 글입니다.


관리 방식

SCM은 '협업'을 위한 툴이므로 소스 파일을 어떻게 관리하는 지가 중요하죠.
일단 간단한 방식은 파일에 lock을 거는 것입니다. 비주얼 소스 세이프나 소스 오프사이트가 이런 방식입니다.
한 사람이 파일 고치고 있으면 아무도 못 건드립니다. 제가 lock 걸어놓고 깜박 잊고 퇴근했다가 두바이에서 걸려온 전화를 받은 적이 있습니다(실화입니다). -_-;;;
구현은 간단하지만 협업에 불편한 점이 많죠 아무래도...

실제 많이 쓰는 방식은 Version Merge입니다. CVS부터 해서 많은 툴들이 이 방식을 씁니다.
이 방식은 여러 개발자가 동시에 같은 파일을 수정할 수 있다는 장점이 있습니다. 수정이 끝나고 저장소에 체크인할 때, 앞번 개발자가 체크인한 코드와 merge를 해야 되는 거죠. 물론 이 merge 과정은 기본적으로 툴이 제공해주어야 하는 기능입니다만, 같은 부분을 수정했을 경우 conflict가 날 수 있습니다. 이 때는 개발자가 직접 manual merge를 해야겠죠. 그래도 이 방식이 훨씬 편합니다 -_- 하지만 auto merge에 대한 알고리즘 구현이 중요하겠죠.


구 조

대개는 클라이언트-서버 방식으로 구현되었습니다만 최근엔 분산 관리방식의 툴들도 많습니다. 서버가 필요없이 개개인의 작업 디렉토리가 저장소가 되는, P2P에 가까운 방식이라고 할 수 있겠군요.
좀 유명한 것들은 대개 CS 방식이고, 분산 관리도구는 리눅스 커널의 버전 관리 툴은 GIT와 요즘 뜨고 있는 Mercurial, Darcs 등이 있습니다.

CS방식은 굳이 설명할 필요가 없을 것 같고... 분산 관리방식은 서로 변경 내용을 보내주거나 받는 방식으로(보통 pull, push라고 칭하더군요) 공유가 되는데, 직접 개발에 적용해 본 적이 없어서 무어라 평가하긴 힘들지만 쉽지는 않을 것 같은 생각이 듭니다.
즉, 기준이 되는 저장소가 없을 경우 커뮤니케이션 관리가 제대로 되지 않는다면 같은 버그가 여러 번 수정되는 경우가 생길 수도 있을 것 같기도 하군요. 하긴 회사든 오픈 소스든 개발하는 사람들끼리 그 정도도 커뮤니케이션이 안되면 문제가 있는 거겠죠 -_-
공유하는 방식은 http 프로토콜을 쓰기도 하고 email로 패치를 보내주는 방식도 쓰고 다양합니다. 자체 서버를 마련할 수 없는 경우라든가 또 서버가 자주 먹통이 되는 경우 -_- 도움이 많이 되겠지요.


Branch

개발하다 보면 기능 추가를 하거나 등등 '기존 소스 트리를 유지하면서 개발'할 필요가 꼭 생깁니다. 이럴 때에 브랜칭을 하게 되지요. 현재의 소스 트리가 복제된다고 보시면 됩니다. 소스 트리에 '가지'가 하나 더 생기는 것입니다.
물론 유지한다고 해도 기존 트리를 전혀 수정하지 않는단 얘기는 아니지요. 안정성에 문제가 없는 한에서는 기존 소스 트리도 수정은 계속 이루어지고 브랜치는 기능 개발을 계속 하게 됩니다. 그리고 어느 시점이 되면 다시 메인 트리에 브랜치를 머지합니다.
브랜치 기능은 SCM 툴에 반드시 필요한 기능 중에 하나라고 할 수 있습니다.


Tag

소스 스냅샷에 꼬리표(tag)를 다는 기능입니다. 보통은 버전에 따라 달게 되겠지요.
물리적인 특정 시점의(예를 들면 몇월 몇일 당시의 소스) 소스 스냅샷을 얻는 것은 툴에서 제공하므로 대개 어렵지 않지만 논리적인 시점이라면 툴이 판단할 수 없는 문제지요. 1.0-beta를 릴리즈한 시점의 소스라든가 하는 경우는 체크해 놓지 않으면 소스 스냅샷을 찾아 보기는 힘들겠죠.
태그를 설정해 놓으면 태그 이름만 입력하는 것으로 해당 태그 시점의 스냅샷을 얻을 수 있습니다.

이것도 매우 기본적인 기능의 하나입니다만, 가장 유명한 SCM 툴의 하나인 Subversion의 경우는 브랜치나 태그를 모두 지원하지 않습니다. 저장소 내의 소스 디렉토리 카피를 통해서 브랜칭이나 태깅을 할 수 있도록 지원하는데 내부 구조는 모르지만 디렉토리 카피가 저장소 용량을 늘리는 거 같지는 않더군요.


Merge

Locking 방식 툴에서는 필요없는 부분이지만 Version Merge 방식의 툴에서는 반드시 필요한 기능입니다.
하지만 이 기능은 내부적으로 수행되며 Merge 알고리즘도 여러가지가 있다고 하는데 잘 모르겠네요 ^^;


Blame

annoatate라고 부르는게 일반적인지도 모르겠습니다만... 개인적으로는 이 기능을 중요시 여깁니다. 문제 생겼을 때에 범인 추적하기에 좋거든요 -_-;
소스 라인별로 최종 수정된 리비전과 수정자의 id를 표시해주는 기능입니다.


Hook

커밋 전이나 커밋 후에 자동적으로 스크립트를 실행하게 해 줍니다.
커밋 될 때마다 코딩 스타일 툴을 실행해서 코딩 스타일을 맞춘다거나 커밋 전에 유닛 테스팅을 실행한다거나 하면 아주 도움이 되겠죠.


대략 이 정도면 기본적인 기능들인 거 같군요.
제가 써 본 건 사실, CVS, Subversion, 소스 오프사이트(비주얼 소스세이프) 정도 뿐입니다만 요즘은 분산 관리툴이 많이 유명한 거 같아 다음에는 그것들에 관해 정리해 볼까 합니다.

SCM 툴을 쓰더라도 태그나 브랜치 등등을 활용하지 않는다면 기능을 절반도 사용하지 못하는 것이나 마찬가지입니다. 안 쓰신다면 꼭 도입하고, 쓰신다면 기능을 더욱 활용해 보시기 바랍니다.

이올린에 북마크하기(0) 이올린에 추천하기(0)

Coding Horror에서 트랙백합니다.

가려운 곳을 제대로 긁은 글이네요. 구슬이 서말이라도 꿰어야 보배라...-_-

어떤 툴이든 사용하는 것만으로 모든 문제가 해결되지는 않습니다. 마찬가지로 버전 관리 도구 또한 쓰기만 한다고 소스 코드의 히스토리가 잘 관리되는 것은 아닌 것 같습니다. 그간의 경험에 비추어 보면요...

위의 글은 특히 브랜치와 머지에 관해 쓴 글인데, 버전 관리도구를 쓰면서 브랜칭을 쓰지 않으면 '왜 버전 관리 도구를 쓰는가'라고 묻고 있습니다. 브랜치 안해도 도움은 되지요, 소스의 변경 이력이 남는다는 점만 해도 매우 크다고 저는 생각합니다.
하지만 반대로 '브랜치를 제대로 하는가'에 대한 내용도 쓰고 있습니다. 이건 쉽지 않은 문제입니다.
글에서는 피해야 할 브랜치와 머지 패턴(anti-pattern)에 대해 나열해 놓았는데 재미있습니다.

머지 기피증(Merge Paranoia) : 두려움에 머지를 하지 않는다.
머지 매니아(Merge Mania) :개발보다 머지에 과도한 시간을 투자한다.
빅뱅 머지(Big Bang Merge) :머지가 개발의 끝단계로 미뤄지고 결국 모든 브랜치를 동시에 머지하면서 큰 혼란이 생긴다.
끝없는 머지(Never Ending Merge) : 머지가 끝날 것 같지 않다 -_- 머지할게 계속 나온다.
잘못된 머지(Wrong Way Merge) : 과거 버전과 머지한다(버전 관리가 잘못되어서 최신 버전이 구분안됨).
브랜치 매니아(Branch Mania) : 브랜치가 너무 자주, 별 이유없이 만들어진다.
끝없는 브랜치(Cascading Branches) : 브랜치들이 메인 브랜치로 머지되지 않고 계속 가지만 쳐 나간다
미스테리 머지(Mysterious Branches) : 누구도 그 브랜치가 왜 만들어졌는지 모른다.
임시 브랜치(Temporary Branches) : 브랜치에 계속 변경을 시도하고 쌓이면서 영원한 '임시' 브랜치가 되어버린다.
가벼운 브랜치(Volatile Branches) : 안정되지 않은 수준의 브랜치가 계속 다른 브랜치에 공유되고 머지된다.
개발 중지(Development Freeze) : 브랜치하고 머지하고 빌드를 만드는 동안 개발 자체가 진행되지 않는다.
베를린 장벽(Berlin Wall) : 브랜치가 작업에 따라 나눠지지 않고 개발자별로 나눠진다 -_-

브랜칭은 소스 관리에서 매우 중요한 요소입니다만 제대로 브랜치를 다루기는 역시 쉽지 않습니다.
어떻게 보면 개발 외적인 문제라 SVN이나 CVS 사용법을 다룬 책은 있어도 브랜칭이나 태깅의 노하우까지 다룬 책은 거의 없습니다.
위의 사항들 중 제가 있는 회사에 해당되는 것도 몇 있군요, 제게 해당되는 거라고 해야 할 지...ㅡㅡ;

여튼 위의 피해야 할 패턴들을 종합해 보면, 브랜칭 목적이 확실해야 하고 메인 브랜치에 반드시 다시 머지가 되는 것을 목표로 해야 합니다.

브랜칭 목적이란 것은 간단할 수도 있고 복잡할 수도 있지만, 최소한 버전업이나 단일 기능 추가를 위한 브랜치가 가장 바람직하지 않나 싶습니다. 크게 보면 같은 의미일 수도 있겠습니다.
대표적인 것은 리눅스 커널이나 FreeBSD 커널의 개발 방식인데 메인 브랜치는 계속 유지하면서 마이너 버전을 릴리즈하고 메이저 버전의 업데이트를 위한 브랜치는 따로 따서 머지 시점까지 계속 개발을 하는 것입니다.

메이저 버전의 업데이트란 것은 구조 변경이나 기능 추가가 중점적이기 때문에 현재 버전의 브랜치에 개발하다가는 릴리즈 버전에 불안정한 버그가 포함될 수 있습니다. 즉, 메인 브랜치는 안정화를 위해 개발력을 투자하고 메이저 버전 업데이트 브랜치는 기능을 추가하거나 구조를 변경하는 작업을 한 후 최종적으로 머지와 테스트를 해서 다음 메이저 버전을 릴리즈하는 것입니다.

단일 기능 추가를 위한 브랜치는 좀 더 직관적입니다. 브랜치 자체를 'thread 지원', '암호화 기능 지원' 등의 단일 기능 추가를 위한 목적으로 따서 개발하고 머지하는 것입니다.

말은 쉬운데, 그렇다면 왜 위에서 열거한 경우가 생기는 것일까요? ㅡㅡ
모든 경우를 경험해 보진 않았지만, 많은 경우는 프로젝트 매니징과 관련이 있습니다. 프로젝트 매니저가 확실한 개발 로드맵을 정하고 개발을 진행시켜야 하는데, 중간에 계속 우선순위가 바뀌거나 한다면 개발하던 브랜치가 쓸모없어지는 경우가 많습니다.
건드리지 않은 채로 브랜치가 오랜 시간이 지나면, 만들었던 사람조차 '내가 왜 이걸 만들었지?'라고 고민하게 되거나, '지금 상황에선 필요없어졌는데..'라거나 '작업했던게 아까우니 일단 놔두자' 이런 식으로 흘러가게 됩니다.

브랜치(branch)란 이름을 누가 붙였는지 모르겠지만, 참 잘 붙인 것 같다는 생각이 드네요. 브랜치도 실제 화분처럼 신경을 안 쓰고 냅두면 말라 비틀어집니다. 그리고 때가 되면 가지치기를 해야 하듯, 머지해야 할 시점에서는 머지가 필요하다는 판단을 내릴 수 있어야 합니다.
물론 머지하기 전에 추가한 내용에 대한 기본적인 테스트가 필요하며, 머지한 후에도 이상이 없는지 테스트를 잘 해보아야하겠지요. 머지 뿐 아니라 개발과 관련된 두려움을 없애는 가장 좋은 방법은 테스트입니다.

모든 것이 다 별개인 것처럼 보이지만 결국 다 이어져 있게 마련입니다.
개발이나 프로그래밍이란 단어에는 코딩 뿐 아니라 위에 언급한 것들까지도 모두 포함되는 것이 맞겠지요. 좋은 개발자가 된다는 것은 역시 쉽지 않습니다.

이올린에 북마크하기(0) 이올린에 추천하기(0)