Subversion의 전략적 활용법
출처: http://www.onurmark.co.kr/?p=474
Flexible vs. Strategic
Subversion은 대단히 유연한 시스템이라서 trunk, branch, tag의 별다른 구분없이 사용 할 수 있으나 이는 다수의 사람이 공용으로 사용하는 경우에 전략이 없으면 매우 혼돈스럽게 변해 버린다는 단점이 있다. 일예로 대부분의 버전관리시스템은 branch와 tag를 할 경우에 특별한 명령어를 사용하나 subversion은 copy 명령어 하나로 수행해 버린다. 처음 접하는 입장에서는 branch와 tag 모두 copy 명령으로 수행할 수 있는데 어떻게 두가지 용도가 다를 수 있다고 생각 할 수 있겠는가?
일단 subversion에서는 trunk, branch, tag는 특별히 구분되는 방법이 없이 그냥 디렉토리로 인식한다. 사용자가 직접 이것은 이런 용도로 사용하겠다고 생각을 하고 사용을 해야 된다는 뜻이다.
- trunk: 메인 소스가 저장되는 공간이다.
- branch: trunk의 사본을 담고 있으며 개발자에 의해 직접 수정 되는 공간
- tags: 개발의 한 주기가 끝날 경우에 tag를 달아 스냅샷을 저장하는 공간
위의 내용은 앞으로 내가 이런식으로 사용하겠다고 정의한 것이다. 다른 포스트나 프로젝트에서는 다르게 활용하고 있을 수도 있다.
Developer’s strategic work flow
프로젝트에 참여한 개발자들의 전략적 흐름은 아래와 같이 정의하였다.
- 새로운 이슈가 발생하면 trunk로 부터 branch를 한다.
- branch로 부터 checkout을 하여 개발을 시작한다.
- 이슈 해결이 끝났을 경우 trunk의 Head revision을 가져와(checkout 또는 update) 자신의 작업 내용을 trunk에 반영한다.
- 작업했던 branch를 삭제한다.
작업을 merge 하기 위해서는 3가지가 필요하다.
- Branch의 최초 revision
- Branch의 head revision
- Trunk의 head revision
A는 R20으로부터 branch하여 R21을 생성하였고 작업이 완료되었을 때 R24가 되었다. 자신의 작업내용을 trunk에 적용하려면 R24-R21의 차이점을 구해 trunk의 head revision(R20)에 적용하면 된다.
B의 경우 R20으로부터 branch하여 R22를 생성하였고 작업이 완료되었을 때 R26이 되었다. 자신의 작업내용을 trunk에 적용하기 위해 R26-R22의 차이점을 구해서 trunk의 head revision(R25)에 적용하면 된다.
이렇게되면 A의 작업과 B의 작업이 손실없이 trunk에 적용이 된다. 물론 trunk에 작업 내용을 merge할 경우 충돌이 발생 할 수 있으며 충돌이 발생한 부분은 해결해 주어야 한다. 성공적으로 merge가 되었으면 작업내용을 trunk로 commit한 후 자신의 branch는 삭제를 하여 재사용하지 않도록 하자. R24와 R26은 자신이 작업한 내용만 들어있는 branch이다. 다음 작업을 시작할때는 trunk에서 새로 branch해서 사용해야 한다.
이 방법의 장점은
- 개발자의 실수로 부터 trunk를 보호 할 수 있으며
- branch내에서는 개발자의 자유로운 행동을 보장해주며
- 개발중에도 trunk가 항상 실행가능한 코드로 유지 할 수 있고
- trunk의 로그를 지저분하게 하지 않아 작업 단위로 분석 할 수 있게 해준다.
이외에도 버전관리시스템을 다루는 여러 전략이 있을 수 있다. 팀과 프로젝트의 성격에 따라 적합한 전략을 선택해서 사용하도록 하는게 좋다.