1Chapter. 브랜치(branch)와 merge

1.2.1. 브랜치(branch)의 작성

브랜치(branch)의 작성은 매우 간단합니다 svn copy 커멘드를 이용해서 저장소(repository)에 있는 프로젝트를 복사하기만 하면 됩니다. Subversion는 하나의 파일만 복사할 수 있는 것이 아니라, 디렉토리 전체를 카피할 수도 있습니다. 당신이 /calc/trunk 디렉토리의 카피를 갖고 싶다고 가정 합니다. 새로운 카피는 어디에 두면 좋을까요? 어디에 두어도 상관이 없습니다. 어디에 두는지는 전적으로 프로젝트 팀의 정책에 따릅니다. 우리팀의 정책은 저장소(repository)의/calc/branches 구역에 브랜치(branch)를 모아두는 것이고, 새로 만들 브랜치(branch) 이름은 "my-calc-branch" 로 합시다. /calc/trunk을 복사해서 /calc/branches/my-calc-branch라고 하는 새로운 디렉토리 를 만들 것입니다.

카피를 만드는 데에는 두 가지 방법이 있습니다. 개념을 확실히 하기 위해 복잡한 방법을 먼저 설명하겠습니다. 먼저 저장소(repository)의 루트 (/calc)를 작업 카피에 체크아웃 합니다:

$ svn checkout http://svn.example.com/repos/calc bigwc
A  bigwc/trunk/
A  bigwc/trunk/
A  bigwc/trunk/Makefile
A  bigwc/trunk/integer.c
A  bigwc/trunk/button.c
A  bigwc/branches
Checked out revision 340.

그리고는, svn copy커멘드에 작업 카피 패스를 둘 건네주는 것만으로 카피를 만들 수 있습니다:

$ cd bigwc
$ svn copy trunk branches/my-calc-branch
$ svn status
A  +   branches/my-calc-branch

이 경우,svn copy 커멘드는 재귀적으로 trunk작업 디렉토리의 내용을 새로운 작업 디렉토리branches/my-calc-branch 에 카피합니다. svn status 커멘드로 확인할 수 있습니다만, 복사된 디렉토리는 저장소(repository)에 새로 더해질 것이라고 예약됩니다. 단, A의 뒤에, +싸인이 표시되는데 주의해주세요. 이것은, 추가 예약이 완전히 새로운 것이 아니라, 무엇인가의 카피 인 것을 나타내고 있습니다. 변경을 커밋하면 Subversion은 네트워크 넘어로 작업 카피 데이터의 전체를 보내는 것이 것이 아니라, /calc/trunk를 카피하는 것으로 저장소(repository)에 /branches/calc/my-calc-branch 를 만듭니다:

$ svn commit -m "Creating a private branch of /calc/trunk. "
Adding      branches/my-calc-branch
Committed revision 341.

그런데, 브랜치(branch)를 만드는 좀 더 간단한 방법이 있습니다. 먼저 설명해야 마땅했습니다 하지만: svn copy 는 인수에 URL를 두 개 취하는 것이 할 수 있다고 하는 것입니다.

$ svn copy http://svn.example.com/repos/trunk/calc \
           http://svn.example.com/repos/branches/calc/my-calc-branch \
      -m "Creating a private branch of /trunk/calc"

Committed revision 341.

이 두 개의 방법에는 아무 차이도 없습니다. 양쪽 모두 새로운 리비전 341의 디렉토리를 만들어, 새롭다 디렉토리는/trunk/calc의 카피에 됩니다. 다만 두번째의 방법은동시에 커밋도 발행합니다. [1] 두번째 방법(URL간 카피)은 즉시 커밋이 일어납니다. 이 방법은 저장소에 있는 많은 파일들을 체크 아웃 해오지 않기 때문에 보다 편리한 방법입니다. 실제로, 이 방법은 실제로는 카피가 전혀 일어나지 않습니다.

1.2.2. 자신용의 브랜치(branch)에서의 작업

이것으로 프로젝트에 새로운 브랜치(branch)를 만들 수가 있었으므로, 새로운 작업 카피를 체크아웃 할 수 있습니다:

$ svn checkout http://svn.example.com/repos/branches/calc/my-calc-branch
A  my-calc-branch/Makefile
A  my-calc-branch/integer.c
A  my-calc-branch/button.c
Checked out revision 341.

There's nothing special about this working copy; it simply mirrors a different directory in the repository. When you commit changes, however, Sally won't ever see them when she updates. Her working copy is of /calc/trunk. (Be sure to read the section called “Switching a Working Copy” later in this chapter: the svn switch command is an alternate way of creating a working copy of a branch.) 이 작업 카피(working copy)에는 굳이 특별한 것은 없습니다. 단지 해당 저장소(repository)의 다른 디렉토리로의 미러링일뿐입니다. 당신이 변경을 커밋할때에도 Sally가 update과는 상관없습니다. (When you commit, She won't ever see them when she updates.) 그녀의 작업 카피는 /calc/trunk 입니다. (이번 chapter이후에 [작업 카피의 변환] 섹션을 꼭 읽으세요 : svn switch 명령어가 브랜치의 작업카피를 새로 만드는 것에 대한 것입니다.

일주일간이 경과하는 동안에, 이하의 커밋이 일어났다고 합시다:

• /branches/calc/my-calc-branch/button.c, (으)로 변경을 더해 리비전 342를 만들었다.

• /branches/calc/my-calc-branch/integer.c, (으)로 변경을 더해 리비전 343을 만들었다.

• Sally는 /trunk/calc/integer.c에 수정을 더해 리비전 344를 만들었다.

이것으로,integer.c에 두 개의 독립했다 개발 라인이 생겼습니다:

integer.c의 카피에 일어난 변경 히스토리를 보면(자) 재미있는 것을 압니다:

$ pwd
/home/user/my-calc-branch

$ svn log integer.c
------------------------------------------------------------------------
r343 | user | 2002-11-07 15:27:56 -0600 (Thu, 07 Nov 2002) | 2 lines

* integer.c:  frozzled the wazjub.

------------------------------------------------------------------------
r303 | sally | 2002-10-29 21:14:35 -0600 (Tue, 29 Oct 2002) | 2 lines

* integer.c:  changed a docstring.

------------------------------------------------------------------------
r98 | sally | 2002-02-22 15:35:29 -0600 (Fri, 22 Feb 2002) | 2 lines

* integer.c:  adding this file to the project.

------------------------------------------------------------------------

Subversion은 카피된 시점까지의integer.c 의 히스토리를 더듬고 있는 것에 주의해 주세요. (브랜치(branch)는 리비전 341 그리고 만들어진 것을 생각해 내 주세요). 이번은 Sally가 자신의 파일 의 카피에 대해서 같은 커멘드를 실행했을 때의 모습을 보겠습니다:

$ pwd
/home/sally/calc

$ svn log integer.c
------------------------------------------------------------------------
r344 | sally | 2002-11-07 15:27:56 -0600 (Thu, 07 Nov 2002) | 2 lines

* integer.c:  fix a bunch of spelling errors.

------------------------------------------------------------------------
r303 | sally | 2002-10-29 21:14:35 -0600 (Tue, 29 Oct 2002) | 2 lines

* integer.c:  changed a docstring.

------------------------------------------------------------------------
r98 | sally | 2002-02-22 15:35:29 -0600 (Fri, 22 Feb 2002) | 2 lines

* integer.c:  adding this file to the project.

------------------------------------------------------------------------

Sally는 자신의 리비전 344의 변경을 볼 수가 있습니다만, 당신이 리비전 343에 한 변경은 볼 수가 없습니다. Subversion에서는, 이 두 커밋은 다른 저장소(repository)의 장소에 있는 다른 파일에 대해 일어납니다. 그러나, Subversion은, 두 개의 파일이 공통의 히스토리를 가지고 있는 것을나타내도 있습니다. 리비전 341 그리고 일어난 브랜치(branch) 카피 전은 양자는 같은 파일을 사용하고 있었습니다. Sally와 당신이 어느쪽이나 리비전 303으로 98을 볼 수가 있는 것은 기타째입니다.

1.2.3. 이 이야기의 교훈

이 마디에서의 중요 사항은 둘입니다.

1. 다른 많은 버전 관리 시스템과는 달라 Subversion의 브랜치(branch)는 저장소(repository)의 보통 파일 시스템 디렉토리 로서 존재합니다. 특별한 구조가 있는 것은 아닙니다.

2. Subversion은 내부적으로는"브랜치(branch)"라는 개념을 가지지 않습니다 그것은 단순한 복사본입니다. 단순히 디렉토리를 복사한 결과가 "브랜치(branch)"인 것은, 여러분이 그러한 의미로 생각하기 때문입니다. 여러분이 그 디렉토리를 다른 의미로 생각하고 다르게 취급할 수도 있지만, 어쨌든 Subversion에게는 복사 의해 작성된 보통 디렉토리일 뿐입니다.

1.3.1. 특정 변경만 카피하기

이전 섹션에서, 당신과 Sally는 서로 다른 브랜치의 interger.c에 변경을 가했습니다. 만약 당신이 Sally가 수정한 리비전 334의 메세지를 통해 Sally가 몇몇 철자 오류를 수정한 것을 알았다고 합시다. 그럼 의심할 여지도 없이 당신의 카피에도 같은 철자 오류가 있을 겁니다. 당신은 곧 같은 철자 오류를 찾아 내어 고칠 것이고, 그 수정은 언젠가 당신의 브랜치를 머지할 때 충돌(conflict)을 일으킬 수 있습니다. 차라리 당신이 같은 곳에 많은 작업을 하기 전에 Sally가 수정한 것을 당신의 브랜치에 적용시키는 것이 더 좋을 것입니다.

이제 svn merge 명령을 사용할 때입니다. 이 명령은 svn diff와 사촌 지간이라고 할 수도 있습니다. (diff 명령은 3장에 설명되어 있습니다) 두 명령어 모두 저장소(repository)에 있는 어떤 두 오브젝트를 비교하여 그 차이점을 알려줍니다. 예로, 당신은 svn diff 명령을 써서 샐리가 리비전 334에서 무엇을 변화 시켰는지 정확히 알아낼 수 있습니다.

$ svn diff -r 343:344 http://svn.example.com/repos/trunk/calc

Index: integer.c
===================================================================
--- integer.c	(revision 343)
+++ integer.c	(revision 344)
@@ -147, 7 +147, 7 @@
     case 6:  sprintf(info->operating_system, "HPFS (OS/2 or NT)"); break;
     case 7:  sprintf(info->operating_system, "Macintosh"); break;
     case 8:  sprintf(info->operating_system, "Z-System"); break;
-    case 9:  sprintf(info->operating_system, "CPM"); break;
+    case 9:  sprintf(info->operating_system, "CP/M"); break;
     case 10:  sprintf(info->operating_system, "TOPS-20"); break;
     case 11:  sprintf(info->operating_system, "NTFS (Windows NT)"); break;
     case 12:  sprintf(info->operating_system, "QDOS"); break;
@@ -164, 7 +164, 7 @@
     low = (unsigned short) read_byte(gzfile);  /* read LSB */
     high = (unsigned short) read_byte(gzfile); /* read MSB */
     high = high  8;  /* interpret MSB correctly */
-    total = low + high; /* add them togethe for correct total */
+    total = low + high; /* add them together for correct total */
 
     info->extra_header = (unsigned char *) my_malloc(total);
     fread(info->extra_header, total, 1, gzfile);
@@ -241, 7 +241, 7 @@
      Store the offset with ftell() !  */
 
   if ((info->data_offset = ftell(gzfile))== -1) {
-    printf("error: ftell() retturned -1. \n");
+    printf("error: ftell() returned -1. \n");
     exit(1);
   }
 
@@ -249, 7 +249, 7 @@
   printf("I believe start of compressed data is %u\n", info->data_offset);
   #endif
   
-  /* Set postion eight bytes from the end of the file.  */
+  /* Set position eight bytes from the end of the file.  */
 
   if (fseek(gzfile, -8, SEEK_END)) {
     printf("error: fseek() returned non-zero\n");

svn merge도 거의 같은 역활을 합니다. 당신의 터미널에 차이점을 뿌려주는 대신에, merge는 차이점을 당신의 작업 카피에 로컬 변경으로 직접 적용 시킵니다.

$ svn merge -r 343:344 http://svn.example.com/repos/trunk/calc
U  integer.c

$ svn status
M  integer.c

위의 svn merge의 출력 결과가 의미하는 것은 당신의 카피본인 interger.c가 패치 되었다는 것입니다. 이제 이 파일은 Sally가 수정한 것을 포함합니다. 다르게 얘기하면 수정 사항이 trunk에서 당신의 작업 카피인 개인용 브랜치로 카피 되었다는 것입니다. 이 시점에서 당신의 로컬 변경을 체크해서 제대로 돌아가는지 확인하는 작업이 더 필요합니다.

좀 일이 안풀리는 시나리오를 가정해 봅시다. interger.c를 merge시켰을대 충돌이 일어났습니다. 정식대로 이 충돌을 해결할 수도 있고 (3장을 참고하세요), 당신이 방금한 병합(merge)이 별로 좋지 않았다고 생각한다면 svn revert명령을 사용하여 로컬 변경을 되돌릴 수도 있습니다.

하지만, 당신이 병합된 파일을 확인하고, svn commit으로 변경을 적용시키는 일반적인 경우를 봅시다. 이 때는 변경이 당신의 저장소에 있는 브랜치에 병합됩니다. 버젼 컨트롤에서 쓰는 용어로, 이러한 브랜치 간의 카피를 하는 경우를 변경의 이식(porting changes)라고 합니다.

당신이 로컬 변경을 commit하였을때 로그 메세지로 어떤 브랜치의 리버젼으로 부터 어떤 변경을 이식하였는지 명시해야만 합니다. 예로

$ svn commit -m "integer.c: ported r344 (spelling fixes) from trunk."
Sending        integer.c
Transmitting file data .
Committed revision 360.

이것은 다음 장에서 곧 배울 중요한 "최고의 습관"입니다.

$ svn diff -r 343:344 http://svn.example.com/repos/trunk/calc > patchfile
$ patch -p0   patchfile
Patching file integer.c using Plan A...
Hunk #1 succeeded at 147.
Hunk #2 succeeded at 164.
Hunk #3 succeeded at 241.
Hunk #4 succeeded at 249.
done

주의: svn diff와 svn merge는 개념적으로 매우 비슷하지만, 구문적으로는 많은 틀린 점을 가지고 있습니다. 자세한 내용은 9장이나 svn help를 참조하시기 바랍니다. 예를 들어svn merge는 타깃 인자로 작업본의 경로를 필요로 합니다. 예로 트리의 변경을 적용하는 장소 같은 곳 입니다. 타깃을 지정해 주지 않으면, 당신이 다음과 같은 일반적인 작업을 실행하려고 한다고 생각합니다.

1. 디렉터리의 변경을 당신이 현재 작업하고 있는 디렉터리에 병합(merge)하려고 한다.

2. 파일의 변경을 현재 작업하고 있는 디렉터리에 있는 같은 이름의 파일에 병합(merge)하려고 한다.

타깃 경로를 지정하지 않고 디렉터리를 병합(merge)하려 하는 경우, svn merge는 현재 상황을 첫 번째 경우라 생각하고 당신의 현재 작업 디렉터리에 변경을 적용시키려고 합니다. 만약 당신이 특정 파일을 병합하려 하고, 그 파일과 같은 이름의 파일이 당신의 작업 디렉터리에 존재한다면, svn merge는 두 번째 경우라 생각하고 같은 이름의 로컬 파일에 변경을 적용시키려 합니다

만약 당신이 다른 곳에 변경을 적용시키려 할 경우에는, 그것을 명시해야 합니다. 예로, 당신의 작업공간 상위 디렉터리에 있을 경우, 변경을 적용할 타깃 디렉터리를 설정해 줘야 합니다.

$ svn merge -r 343:344 http://svn.example.com/repos/trunk/calc my-calc-branch
U   my-calc-branch/integer.c

1.3.2. 병합할 때 좋은 습관들

$ svn merge --dry-run -r 343:344 http://svn.example.com/repos/calc/trunk
U  integer.c

$ svn status
#  nothing printed, working copy is still unchanged.

1.3.3. 브랜치(branch) 전체의 merge

지금, 생각해 온 예를 완결시키기 (위해)때문에, 조금 시간이 경과했다고 합니다. 며칠인가 경과해, 많은 변경이 trunk에도 선반의 사적인 브랜치(branch)에도 오코시. 그리고 당신은 사적인 브랜치(branch)상에서의 작업을 끝냈다고 합시다; 기능 추가, 또는 버그 픽스(bug-fix)가 완료해, 다른 사람이 그 부분을 사용할 수 있도록(듯이) 하기 위해서, 당신의 브랜치(branch)상의 변경점의 모든 것을 trunk 에 merge 하고 싶다고 합니다.

그런데, 이러한 상황에서는, 어떻게 해svn merge (을)를 사용하면 좋은 것일까요? 이 커멘드는 두 개의 트리를 비교해, 그 차분을 작업 카피에 적용하는 것인 것을 생각해 내 주세요. 변경점 (을)를 받기 위해서(때문에)는, 당신은 trunk의 작업 카피를 손에 넣을 필요가 있습니다. 여기에서는 당신은(완전하게 갱신된) 원래의 작업 카피를 아직 가지고 있는지, /trunk/calc의 새로운 작업 카피를 체크아웃 한 것 (와)과 가정합니다.

그러나, 어느 트리와 어느 트리를 비교하면 좋은 것일까요? 조금 생각하면(자), 그 대답은 분명하게 생각됩니다: 단지 trunk의 최신의 트리와 당신의 브랜치(branch)의 최신의 트리입니다. 그러나, 조심해 주세요 이 가정은잘못해입니다. 그리고 이전 차이에, 대부분의 초심자는 당해 버립니다! svn merge는svn diff와 같이 일하므로 마지막 트렁크와 브랜치(branch)의 트리의 비교는 단지 당신이 자신의 트리에 대해서 간 변경점만을 나타내는 것이아니다 의를 알 수 있습니다. 그러한 비교는, 매우 많은 변경을 표시하겠지요: 그것은, 당신의 브랜치(branch)에 대한 추가점만을 표시하는 것이 아니라, 당신의 브랜치(branch)에서는 결코 일어나지 않았다, trunk상의 변경점의취소도 표시해 버리겠지요.

당신의 브랜치(branch)상에 일어난 변경만을 나타내려면 , 당신의 브랜치(branch)의 초기 상태와 최종적인 상태를 비교할 필요가 있습니다. svn log커멘드를 당신의 브랜치(branch)상에서 사용하면, 그 브랜치(branch)는 리비전 341으로 만들어진 것을 알 수 있습니다. 그리고, 브랜치(branch) 의 최종적인 상태는, 단지, HEAD 리비전을 지정하면 압니다.

결국, 최종적인 merge 처리는 이하와 같이 됩니다:

$ cd trunk/calc

$ svn merge -r 341:HEAD http://svn.example.com/repos/branches/calc/my-calc-branch
U   integer.c
U   button.c
U   Makefile

$ svn status
M   integer.c
M   button.c
M   Makefile

[examine the diffs, compile, test, etc. ]

$ svn commit -m "Merged all my-calc-branch changes into the trunk. "

1.6.1. 간단한 태그의 작성

한번 더,svn copy 의 도움을 받습니다. 만약 HEAD 리비전의/trunk/calc 의 스냅 쇼트를 만들고 싶을 때에는, 그 카피를 취하면 좋기 때문에 했다:

$ svn copy http://svn.example.com/repos/trunk/calc \
           http://svn.example.com/repos/tags/calc/release-1. 0 \
      -m "Tagging the 1.0 release of the 'calc' project. "

Committed revision 351.

이 예에서는/tags/calc 디렉토리가 벌써 존재하고 있는 것으로 하고 있습니다. 카피 완료 후, 새롭다 release-1. 0 디렉토리는, 당신이 카피했다 시점의 HEAD 리비전에 대해 프로젝트가 어떻게 보이고 있었는지를 스냅 쇼트로서 영원히 남기는 것입니다. 물론, 어느 리비전을 카피할까에 임해서 좀 더 정확하고 싶으면 생각할지도 모릅니다. 다른 사람이 당신이 보지 않을 때에 프로젝트에 대해 변경점을 커밋하고 있었을지도 모르지 않기 때문에. 만약 당신이 /trunk/calc 의 리비전 350이 자신의 가지고 싶은 스냅 쇼트라고 알고 있으면svn copy 커멘드에 -r 350을 지정할 수가 있습니다.

그렇지만 조금 기다려 주세요: 이 태그 작성의 수속은 브랜치(branch)를 만든다 위해(때문에) 사용해 온 수속과 같지 않아? 실은 그렇습니다. Subversion 에서는 태그와 브랜치(branch)에는 차이는 없습니다. 양쪽 모두 카피로 만들어진 보통 디렉토리입니다. 정확히 브랜치(branch)와 같이 카피된 디렉토리가"태그"이다고 말해지는 것은, 단지 인간이그렇게 취급하기로 결정했기 때문에, 다만 그것 뿐입니다. 그 디렉토리에 아무도 커밋하지 않는 한, 그것은 영원히 snapshot로서 남습니다. 만약 누군가가 거기에 커밋 하기 시작하면(자), 그것은 브랜치(branch)가 됩니다.

만약 저장소(repository)를 관리하고 있다면, 태그를 관리하려면 2통의 방법이 있습니다. 최초의 어프로치는,"유저 맡김"입니다. 프로젝트 폴리시로서 당신의 태그를 두는 장소를 결정해 모든 유저에게 그 디렉토리를 카피할 때에는 어떻게 취급할까 (을)를 알립니다. (즉, 모두가 거기에 커밋하지 않게 약속합니다) 두번째의 방식은 좀 더 가치가치입니다. Subversion가 제공하는 액세스 제어 스크립트의 어떤 것인지를 사용해, 태그 area에는 새로운 카피를 만드는 것만이 할 수 있어, 그 이외의 조작을 금지합니다. (###cross-ref a section that demonstrates how to use these scripts? ). 가치가치 방식은, 보통은 불필요합니다. 만약 유저가 잘못해 태그 디렉토리 (으)로 자신의 변경을 커밋해 버리면(자), 전의 장으로 설명한 방법으로 그 변경을 취소하면 좋기 때문에. 결국, Subversion은 버전 관리 시스템인 것입니다.

1.6.2. 복잡한 태그의 작성

가끔, 하나의 리비전의 하나의 디렉토리보다 좀 더 복잡한 snapshot를 갖고 싶은 일이 있습니다.

예를 들어, 프로젝트가 우리의calc 보다 좀 더 크다고 합니다. 많은 서브 디렉토리와 좀 더 많이 의 파일이 있다고 합니다. 일의 과정에서, 특정의 기능과 버그 수정을 포함했다 작업 카피가 필요하게 되었다고 판단합니다. 특정의 리비전의 파일과 디렉토리를 선택해(svn update -r liberally 를 사용해), 이것을 만들 수도 있고, 특정의 브랜치(branch)에 파일과 디렉토리를 스윗치 하는 것에 의해도 할 수 있습니다. (svn switch를 사용한다) 이것을 하면(자), 당신과 작업 카피는 다른 리비전으로부터 되는 다른 저장소(repository) 위치의 다음 벗기가 됩니다. 그러나 테스트 후, 자신이 확실히 필요와 하고 있는 편성인 것을 알 수 있었습니다.

자 snapshot를 취합니다. 하나의 URL를 작업하고 있지 않는 다른 장소에 카피합니다. 이 경우, 하고 싶은 것은 특정의 작업 카피 상태 그리고, 그것을 저장소(repository)에 격납하고 싶습니다. 행운의 일로 svn copy 는 실제로는 4 종류가 다른 사용법이 있습니다. (Chapter 8을 읽어 주세요) 그 중에는 작업 카피 트리 (을)를 저장소(repository)에 카피한다, 라고 하는 것도 있습니다:

$ ls
. /    ../   my-working-copy/

$ svn copy my-working-copy http://svn.example.com/repos/tags/calc/mytag

Committed revision 352.

이것으로 저장소(repository)에 새로운 디렉토리가 생겼습니다. /tags/calc/mytag입니다. 이것은 당신의 작업 카피 의 정확한 snapshot입니다 혼합 리비전, URL 그리고 방법이라고입니다.

다른 유저는 이 기능의 재미있는 사용법을 찾아냈습니다. 가끔, 자신의 작업 카피에 로컬인 수정을 했다 브랜치(branch)가 있지만, 그것을 다른 멤버에게 보여 주고 싶다고 하는 것 같은 상황입니다. svn diff 를 사용해 패치 파일을 보내는(그것은 트리의 변경을 취득할 수 없습니다) 대신에, svn copy를 사용해, 작업 카피를 저장소(repository)의 사적인 area에"업 로드"합니다. 다른 멤버는 작업 카피를 새롭게 체크아웃 하는지,cvs merge (을)를 사용해 변경점만을 받을 수가 있습니다.

1.7.1. 저장소(repository)의 레이아웃

저장소(repository)의 편성에는 어느 정도, 표준화 된, 추천하는 방법이 있습니다. 대부분의 사람들은trunk디렉토리 에 개발의"주계", 브랜치(branch)의 카피가 있는branches 디렉토리, 그리고 태그의 카피가 있는tags디렉토리 (을)를 넣습니다. 저장소(repository)가 단 하나의 프로젝트를 포함한 경우에는 자주, 이 세 개의 디렉토리를 저장소(repository) 최상정도에 만듭니다:

/trunk
/branches
/tags

저장소(repository)가 복수 프로젝트를 포함한 경우는, 브랜치(branch)에 의해 배치를 인덱스화합니다. :

/trunk/paint
/trunk/calc
/branches/paint
/branches/calc
/tags/paint
/tags/calc

또 프로젝트에 따라서는 :

/paint/trunk
/paint/branches
/paint/tags
/calc/trunk
/calc/branches
/calc/tags

물론, 이 표준적인 레이아웃을 무시해도 괜찮습니다. 당신과 팀이 가장 작업하기 쉽게, 이 레이아웃은 어떻게 변화시켜도 괜찮습니다. 어떤 것을 선택해도 그것은 영구히 고정된 것이 아닙니다. 언제라도 저장소(repository)를 재편성 할 수가 있습니다. 브랜치(branch)와 태그는 보통 디렉토리 에 지나지 않기 때문에svn move커멘드를 사용하면 좋아하는 대로 이동, 명칭 변경을 할 수 있습니다. 어느 레이아웃으로부터 다른 레이아웃에의 변환은 단지 서버측에서의 몇회인가의 이동의 이야기가 됩니다. 만약 저장소(repository)중의 편성에 무엇인가 마음에 들지 않는 곳이 있다면, 디렉토리 에 관련한 잔기술을 사용해 주세요.

1.7.2. 데이터의 수명

Subversion 모델의 다른 좋은 기능으로서는 다른 버전 관리된 아이템과 같이, 브랜치(branch)와 태그는 유한의 수명 밖에 가지지 않는다 같게도 할 수 있는 것입니다. 예를 들어calc프로젝트 의 개인적인 브랜치(branch)상에서 모든 작업이 완료했다고 합니다. 모든 변경을,/trunc/calc에 merge 한 후에는 그 개인적인 브랜치(branch)의 디렉토리 완전히 소용 없게 됩니다:

$ svn delete http://svn.example.com/repos/branches/calc/my-calc-branch \
             -m "Removing obsolete branch of calc project. "

Committed revision 375.

이것으로 브랜치(branch)는 없어져 버렸습니다. 물론 정말로 삭제되었다 (뜻)이유가 아닙니다: 디렉토리는 단지 HEAD 리비전으로부터 없어졌다 만으로, 아무도 번거롭게 할 수 있는 것은 없어졌습니다. 만약 이전의 리비전 (을)를 보고 싶은 경우는, (svn checkout -r, svn switch -r, 혹은 svn list -r를 사용해) 낡은 브랜치(branch)를 언제라도 볼 수가 있습니다.

삭제한 디렉토리를 열람하는 것 만으로는 불충분한 경우는, 언제라도 되돌릴 수도 있습니다. 데이터의 restore는 Subversion에서는 문제없습니다. HEAD에 되돌리고 싶은 삭제 디렉토리(또는 파일)가 있는 경우는, 단지 svn copy -r 를 사용해 낡은 리비전으로부터 카피해 주세요:

$ svn copy -r 374 http://svn.example.com/repos/branches/calc/my-calc-branch \
                  http://svn.example.com/repos/branches/calc/my-calc-branch

Committed revision 376.

우리의 예에서는 개인적인 브랜치(branch)는 비교적 짧은 생존 시간을 가집니다. 버그를 고치거나 새로운 기능을 추가하는데 이용했기 때문에입니다. 작업이 끝나면, 브랜치(branch)의 수명도 거기서 마지막입니다. 그러나, 개발 내용에 따라서는 매우 긴 시간에 걸쳐서 두 개의 브랜치(branch)가 병행해 계속 사는 일도 있습니다. 예를 들어, 안정판의calc프로젝트를 공에 릴리스 할 때가 와, 그 소프트의 버그를 취하는데는 몇개월걸린다고 합니다. 릴리스 버전에 새로운 기능을 추가시키고 싶지는 없습니다만, 모든 멤버에게 개발을 중지하도록(듯이) 말해 구도 있어 선. 거기서 대신에, 당신은 그만큼 큰 수정은 발생하지 않는다 "안정판"의 브랜치(branch)를 만듭니다:

$ svn copy http://svn.example.com/repos/trunk/calc \
         http://svn.example.com/branches/calc/stable-1. 0
         -m "Creating stable branch of calc project. "

Committed revision 377.

이것으로 개발자는 최첨단의 기능(혹은 실험적인 기능)을 /trunk/calc에 계속 추가하는 것이 할 수 있어 버그 수정만을/branches/calc/stable-1. 0 에 커밋하는 것 같은 폴리시로 진행할 수가 있습니다. 즉, 멤버가 trunk상에서 계속 작업할 때 , 버그 수정에 붙어 안정판 브랜치(branch)상에 가지고 갈 수가 있습니다. 안정판 브랜치(branch) 하지만 출시된 후에도, 그 브랜치(branch)를 긴 시간 들여 계속 메인트넌스한다 그렇지즉, 고객에 대해서 그 릴리스를 계속 서포트한다 한.