아래는 svn에서 추천하는 repository의 모습이다.
  • project/
    • trunk/
    • branches/
      • new-interface/
      • windows-port/
    • tags/
      • version-1.0/
      • version-1.1/
      • version-2.0/

그래서 보통 하나의 project를 하게 되면, 그 이름의 project directory를 만들고, 그 안에 trunk를 만들어서, 그것을 main stem 으로 쓴다.
만약 calc/ 란 project가 있다면, 그 안에 trunk를 하나 만들어서 file들을 calc/ 에 두는 것이 아니라, calc/trunk/ 안에 두는 것이다.
 
 
Use cases for branch
 
Release Branches
 
보통 branch는 trunk에서 개발하다가, 이정도면 1.0으로 release 할 수 있겠다고 판단 될 때,
branch를 하나 뽑아서 거기서 이제 최종적으로 이 branch가 문제가 없는지 test한다.
그리고 이 test가 끝나면, user에게 1.0을 보이는 것이다.
이 1.0 이 생성되었을 때 tag 1.0 을 붙이게 된다.
 
그리고 trunk에서는 계속해서 2.0을 향해 개발을 진행하게 된다.
그러는 도중에 bug fix를 계속 할 것이고, 이 bug fix는 branch 1.0 에도 행하여 진다.(ported)
그렇게 branch 1.0 에서 계속 bug fix가 진행되다 보면,
1.0.1 release를 하려고 할 것이다.
이 때 또 여기에 tag 1.0.1 를 붙이는 것이다.(branch 1.0 을 tag 1.0.1에 copy하는 것이다.
 
계속 이런식으로 나가게 되면, 최종적으로 trunk에는 최종적으로 개발되고 있는 부분이 있게 되고,
branch는 각 버전의 최신이 있게되면, 즉, "maintenance mode"로 있게 되며
tag에는 최종적으로 배포된 내용(final shipped version)을 갖게 될 것이다.
 
 
Feature Branches
 
release branches 와는 다르게 임시로 만들어 쓰고, 여기서 바뀐 내용은 다시 trunk로 merge 시키고, 자신의 작업이 다 끝나고 나서는 없애버리는 branch 이다.
 
이때 branch에서 너무 따로 작업하게 되면, 나중에 이 branch와 trunk를 merging 하기 힘들어진다. 그래서 이 문제를 해결하기 위한 방법은 자주 trunk의 변경사항을 feature branch에 merging 시키는 것이다.
 
merging을 할 때 주의사항은 svn이 merging에 대한 history를 보관하지 않기 때문에, merging을 하고 commit을 할 때 log message에 꼭 어느 revision 과 merging을 했는지등을 잘 적어놓아야 한다.
그래야, 다음에 또 merging을 할 때 어느 부분까지 merging 되어 있는 지를 알 수 있고,
그 다음 revision부터 merging 하면 되기 때문이다.
같은 부분이 두번 들어가는 경우도 발생할 수 있다.
 
porting :
 한 branch에서 다른 branch(trunk 포함)의 change를 복사해 오는 것.
 
 
Posted by Uzys

댓글을 달아 주세요

  1. Favicon of http://5517.stlouiscores.com ghd 2013.07.29 04:52  댓글주소  수정/삭제  댓글쓰기

    태양이 바다에 미광을 비추면,나는 너를 생각한다.

  2. Favicon of http://2092 michael kors outlet 2013.08.04 06:58  댓글주소  수정/삭제  댓글쓰기

    희미한 달빛이 샘물 위에 떠있으면,나는 너를 생각한다.