Tortoise SVN

어떤 이유에서인지는 모르겠지만, 잘 써오던 소스세이프를 동결하고 Tortoise SVN – 이하 SVN – 을 쓰기 시작했다. 소스세이프와 유사한 프로그램이기는 하지만 몇 가지 다른 개념을 가지고 있고, 파일을 컨트롤하는 규칙 같은 것들이 미묘하게 다르기 때문에 적응하는데 시간이 조금 필요했다. 기존에 프로그램을 하나 따로 실행해야 하는 것과는 달리 쉘에 붙어서 실행되는 것이 어떻게 보면 편해 보이고, 어떻게 보이면 실수의 여지가 있었다. SVN을 사용하기 시작한 지 시간이 조금 지났는데, 지금 사용하는 SVN 클라이언트만의 문제인지도 모르겠지만, 이전에 사용하던 소스세이프 쪽이 기획팀 입장에서는 좀 더 사용하기 편리하다.

소스세이프에서는 ‘Share’ 기능을 잘 사용했다. 여러 가지 각각의 업무 단위에는 여러 가지 문서들이 필요한데, 이 문서들을 분리하는데 이 기능을 사용하면 문서는 하나이지만 각각의 디렉토리에 한 문서의 복사본을 배치해 놓고 그 중 아무거나 하나를 업데이트하면 모든 문서에 반영되는 식이었다. 위키 같은 도구에서는 간단히 생각할 수 있는 방법이지만 윈도우 파일시스템 기반에서는 생각할 수 없었는데, 소스세이프를 이용하면서 파일의 중복 문제가 해결됐다. 예를 들어 ‘NPC 이동 기획서’라는 문서가 있다면, 이 문서는 NPC 디렉토리 – 프로젝트 – 에도, ‘이동’ 디렉토리에도 있을 수 있다. 물론 어느 하나를 수정하면 둘 다 수정된다. 지금은 파일 하나를 수정하면 이 파일을 참조하는 각각의 디렉토리 모두에 수동으로 반영해야 한다.

소스세이프 2005 이상에서 지원하는 ‘Checkout – Modify – Merge’ 모델을 SVN에서는 기본으로 지원한다. 그런데 기획팀에서 사용하는 대부분의 파일은 오피스 문서, 즉 바이너리 형식이기 때문에 동시 작업을 할 수도 없고, 병합할 수도 없다. 그래서 초기에 엑셀파일 하나를 여러 사람이 체크아웃해 작업하다가 다중 추돌 사고가 일어나기도 했다. 결국 모든 파일 속성에 ‘needs lock’ 옵션을 추가해 ‘Lock – Modify – Unlock’ 모델을 사용하도록 바꿨다. 결과는 같지만 소스세이프를 사용하던 때에 비해 조작 순서가 꽤 복잡해져버렸다.

작업자의 작업 방식에 따라 달라질 수 있는 부분이지만, 소스세이프는 일단 파일을 들고 나와 수정한 다음 다시 집어넣는 식, 말하자면 ‘원격 스토리지가 우선’인 성향이 강하고 Tortoise SVN은 일단 로컬에 저장된 파일을 우선시해 작업을 하되 필요한 경우에 따라 서버로부터 업데이트 된 파일을 가져오는 식, 말하자면 ‘로컬 스토리지 우선’인 성향이 강하다. 하지만 위에서 이야기했다시피 동시 수정에 아무런 의미가 없는 이상 원활한 디버그나 빌드 작업을 위해 로컬 스토리지를 우선시해 작업할 의미 같은 건 적어도 기획팀엔 없다. 로컬에 있는 파일을 믿고 작업하다간 큰 코 다치기 십상이다. 물론 프로그램 동네도 비슷하겠지만, 기획팀은 병합도 안 된다.

‘충돌 상태’나, ‘충돌 해결’, ‘Steal Lock’ 같은 기능들은 버전 관리 솔루션을 사용할 때 일어날 수 있는 여러 가지 인간적인 상황에 대비하고 있지만, 때때로 초보자들에게 ‘뒷구멍’같은 것을 만들어주는 결과를 가져올 수도 있다. 충돌을 일으켰다면 스스로 충돌 해결을 누르고 파일을 다시 추가할 수 있다. 이 과정에서 다른 사람이 파일을 수정했다면 그쪽 수정은 날아간다. 소스세이프에서 누군가 파일을 체크아웃하면 그 사람 자리에 가서 체크아웃을 풀거나, 관리자가 개입해야 체크아웃을 풀 수 있는 것은 상대적으로 덜 인간적이지만 버전 관리에 익숙하지 않은 사람들이 겪을 수 있는 실수를 방지한다.

초보자 입장에서, 소스세이프가 별도의 프로그램 하나를 띄우도록 되어 있는 것은 일종의 상징적인 의미가 강하다. ‘이제부터 작업을 시작한다’ 혹은 ‘이제 작업을 끝낸다’는 의미를 가진다. 마치 인도견에게 인도견 장구를 입히는 순간 ‘일이 시작된다’고 인식하는 것과 같다. 프로그램을 실행하거나, 그렇지 않거나는 간단한 차이이지만, ‘파일을 서버로 전송한다’거나, ‘서버로부터 파일을 전송받는다’는 것에 대한 인식을 심어주어 실수의 가능성을 낮춘다. 반면에 쉘에 통합된 구조는 간단해 보이지만 이런 의식적인 제어가 없어 실수를 유발하기도 한다.

이런 이유들로 tortoise SVN은 소스세이프에 비해 기획팀에서 사용하기에 적합하지 않다.

9 Responses to Tortoise SVN

  1. Gloridea says:

    바이너리 파일에서는 그런 측면이 있군요…
    개발자 측면에서는 Update-Commit-Merge 가 주는 대기시간 감소의 효과가 상당합니다. 하지만 리팩토링이랑은 좀 잘 안 어울리는 면도 있구요..

    • Milfy says:

      대기시간을 관리하는 다른 방법이 있다면 바이너리 파일을 수정하기 위한 대기시간도 무리는 없을거같은데, 그런게 없는 상태에서 솔루션을 바로 도입하니 여러 가지로 햇갈리더라구요.

  2. i.k. says:

    예, 일반 바이너리 문서의 버전 관리에는 적합치 않은 듯 합니다.
    그래서 bug tracking 시스템인 trac을 같이 써서 wiki 형태로 문서를 관리하기도 합니다만,
    아무래도 주된 문서 포맷이 뭐냐에 따라 호불호가 갈리겠죠 :)

    • Milfy says:

      위키는 정말, 지난 2년 동안 ‘기획서 포멧에 도입하면 어떨까’를 고민해 온 방법인데, 아무리 생각해도 좋은 방법이지만, 또 아무리 생각해도 MS워드보다 편리하진 않을 것이 사실이라, 난감한 문제입니다. =_=

  3. jalnaga says:

    맞아요. 그래픽 팀도 데이터 관리를 저걸로 하라고 강요하는데 저희는 그냥 제가 짠 스크립트로 데이터 관리를 하고, 데이터를 제 하드로 몰아놓고 제가 매일 코밋하는 식으로 씁니다.
    맥스파일 하나에 연결되는 파일이 몇개씩 있는데 그거 다 체크아웃 하는것도 힘들고 그렇게 하다보니 디렉토리 구조로 텍스쳐를 다 나눠놓고 써야 되고…
    여튼 그래픽 디자이너한테는 정말 않좋습니다.

    • Milfy says:

      자동화 문제에 여러 가지가 걸려서, 어떻게 하면 좋을까 하는 중입니다. 몇 가지 대안이 있기는 한데, 솔루션 자체가 프로그램 동네 사람들을 위해 만들어지다 보니 문제가 많더군요.

  4. 남박사 says:

    날 갈구다니 잊지 않겠다(어?)

  5. 안불렀슈 says:

    워드나 엑셀 같은 사무용 문서 프로그램 용으로도 훌륭한 버전관리 시스템이 나오면 좋겠습니다. MS Back Office 같은 솔루션이나 Office Server 등이 지원을 하는 것 같던데, 이 것은 사용해보지 못했구요~ ^^

    상용 개발 데이터 관리툴 들은 강력한 형상관리/버전관리 기능을 갖고 있던데, 예네들은 가격대도 수억 하더라구요 ^^

    오피스 문서만 사용하신다면, Office Server 제품을 한번 살펴보시면 좋지 않을까 합니다.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>