2007/04/20 00:31
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은 소스세이프에 비해 기획팀에서 사용하기에 적합하지 않다.
소스세이프에서는 'Share' 기능을 잘 사용했다. 여러 가지 각각의 업무 단위에는 여러 가지 문서들이 필요한데, 이 문서들을 분리하는데 이 기능을 사용하면 문서는 하나이지만 각각의 디렉토리에 한 문서의 복사본을 배치해 놓고 그 중 아무거나 하나를 업데이트하면 모든 문서에 반영되는 식이었다. 위키 같은 도구에서는 간단히 생각할 수 있는 방법이지만 윈도우 파일시스템 기반에서는 생각할 수 없었는데, 소스세이프를 이용하면서 파일의 중복 문제가 해결됐다. 예를 들어 'NPC 이동 기획서'라는 문서가 있다면, 이 문서는 NPC 디렉토리 - 프로젝트 - 에도, '이동' 디렉토리에도 있을 수 있다. 물론 어느 하나를 수정하면 둘 다 수정된다. 지금은 파일 하나를 수정하면 이 파일을 참조하는 각각의 디렉토리 모두에 수동으로 반영해야 한다.
소스세이프 2005 이상에서 지원하는 'Checkout - Modify - Merge' 모델을 SVN에서는 기본으로 지원한다. 그런데 기획팀에서 사용하는 대부분의 파일은 오피스 문서, 즉 바이너리 형식이기 때문에 동시 작업을 할 수도 없고, 병합할 수도 없다. 그래서 초기에 엑셀파일 하나를 여러 사람이 체크아웃해 작업하다가 다중 추돌 사고가 일어나기도 했다. 결국 모든 파일 속성에 'needs lock' 옵션을 추가해 'Lock - Modify - Unlock' 모델을 사용하도록 바꿨다. 결과는 같지만 소스세이프를 사용하던 때에 비해 조작 순서가 꽤 복잡해져버렸다.
작업자의 작업 방식에 따라 달라질 수 있는 부분이지만, 소스세이프는 일단 파일을 들고 나와 수정한 다음 다시 집어넣는 식, 말하자면 '원격 스토리지가 우선'인 성향이 강하고 Tortoise SVN은 일단 로컬에 저장된 파일을 우선시해 작업을 하되 필요한 경우에 따라 서버로부터 업데이트 된 파일을 가져오는 식, 말하자면 '로컬 스토리지 우선'인 성향이 강하다. 하지만 위에서 이야기했다시피 동시 수정에 아무런 의미가 없는 이상 원활한 디버그나 빌드 작업을 위해 로컬 스토리지를 우선시해 작업할 의미 같은 건 적어도 기획팀엔 없다. 로컬에 있는 파일을 믿고 작업하다간 큰 코 다치기 십상이다. 물론 프로그램 동네도 비슷하겠지만, 기획팀은 병합도 안 된다.
'충돌 상태'나, '충돌 해결', 'Steal Lock' 같은 기능들은 버전 관리 솔루션을 사용할 때 일어날 수 있는 여러 가지 인간적인 상황에 대비하고 있지만, 때때로 초보자들에게 '뒷구멍'같은 것을 만들어주는 결과를 가져올 수도 있다. 충돌을 일으켰다면 스스로 충돌 해결을 누르고 파일을 다시 추가할 수 있다. 이 과정에서 다른 사람이 파일을 수정했다면 그쪽 수정은 날아간다. 소스세이프에서 누군가 파일을 체크아웃하면 그 사람 자리에 가서 체크아웃을 풀거나, 관리자가 개입해야 체크아웃을 풀 수 있는 것은 상대적으로 덜 인간적이지만 버전 관리에 익숙하지 않은 사람들이 겪을 수 있는 실수를 방지한다.
초보자 입장에서, 소스세이프가 별도의 프로그램 하나를 띄우도록 되어 있는 것은 일종의 상징적인 의미가 강하다. '이제부터 작업을 시작한다' 혹은 '이제 작업을 끝낸다'는 의미를 가진다. 마치 인도견에게 인도견 장구를 입히는 순간 '일이 시작된다'고 인식하는 것과 같다. 프로그램을 실행하거나, 그렇지 않거나는 간단한 차이이지만, '파일을 서버로 전송한다'거나, '서버로부터 파일을 전송받는다'는 것에 대한 인식을 심어주어 실수의 가능성을 낮춘다. 반면에 쉘에 통합된 구조는 간단해 보이지만 이런 의식적인 제어가 없어 실수를 유발하기도 한다.
이런 이유들로 tortoise SVN은 소스세이프에 비해 기획팀에서 사용하기에 적합하지 않다.
Tortoise SVN, 기획, 버전 관리, 일
