TortoiseSvn -svn Merging 챕터 번역

TortoiseSvn -svn Merging 챕터 번역 

출처: http://postgame.tistory.com/404

svn 사용하다 필요한 부분이 있어 검색중 번역해 놓은 곳이 퍼옴~ (정보는 공유되어야 한다 쭈욱~)

4.20.머징

브랜치는 분리된 개발 라인을 유지하는 곳으로, 어느단계에 이르면 당신은 브랜치에서 만든 수정을 트렁크로 머지하고 싶어질 것입니다. 혹은 반대로요.

 

당신이 이것을 이용하기 전에 서브버젼의 브랜칭과 머징 작업을 이해하는 것은 매우 중요합니다. 이것은 꽤 복잡할 수 있고요. 서브버젼 책에서 Branching and Merging 챕터를 읽어보길 매우 추천합니다. 여기에 대한 많은 예제와 자세한 설명이 있습니다.

 

그리고 머징은 항상 워킹 카피가 있는 장소에서만 할 수 있는 것에 유의하세요. 만약 브랜치에 수정을 머지하길 원한다면, 브랜치를 체크아웃 받아 워킹 카피를 가지고 있어야만 합니다. TortoiseSVN->Merge...을 사용해 워킹 카피에서 머지 위저드를 실행하면 됩니다.

 

일반적으로 수정하지 않은 워킹 카피로 머지를 하는 것이 좋습니다. 만약 워킹카피에 다른 수정을 가했다면, 먼저 커밋하세요. 머지가 당신의 기대처럼 진행되지 않는다면, 수정을 리버트하길 원할지도 모릅니다. 리버트 커맨드는 당신이 머지 이전에 작성했던 모든 수정을 버리게 됩니다.

 

아래에 설명하는 약간씩 다른 3가지 공통 유즈 케이스들이 있습니다. 머지 위저드의 첫 페이지에서 필요한 방법을 선택할 수 있게 묻게 됩니다.

 

Merge a range of revisions

이 방법은 브랜치나 트렁크로 하나 혹은 그 이상의 리비젼을 가지고 있고, 다른 브랜치로 수정을 옮기길 원할 때 유용합니다.

 

당신이 서브버젼에 이 작업을 하는 것은 이것과 같습니다. : 브랜치A의 리비젼1~7까지 수정을 계산해서 이를 내 워킹 카피(트렁크나 브랜치B)에 적용하시오.

 

Reintegrade a branch

이 방법은 서브버젼 책에서 논한 특정 브랜치를 만들때 사용합니다. 모든 트렁크 수정을 특정 브랜치에 반영하게 되면 한주 두주 지나면서 특정 기능이 완료되고 당신은 트렁크로 다시 머지하길 원할 것입니다. 특정 브랜치를 트렁크와 동기화 해왔기 때문에 브랜치의 마지막 버젼과 트렁크는 당신의 브랜치의 수정에 대해 완벽하게 동일한 예외를 가지게 됩니다.

이것은 아래 설명한 트리 머지의 특별한 경우입니다. 일반적으로 당신의 개발 브랜치로 부터 머지하기 위해서 URL만 요구합니다. 이때 현재 리비젼 범위를 계산해서 서브버젼의 머지 트래킹 기능을 사용하며, 브랜치가 트렁크 수정을 모두 업데이트되었는지, 보장하는 부가적인 체크를 합니다. 이것은 트렁크에 다른데서 커밋된 것을 당신이 마지막 수정 동기화 이후에 우연히 undo하지 않는 것을 보장합니다.

 

머지 이후, 모든 브랜치 개발은 메인 개발 라인에 완전히 머지 될 것입니다. 그럼 이 브랜치는 이제 불필요하고 삭제할 수 있습니다.

 

한번 재통합 머지를 이행하면 개발을 위해 이 브랜치를 사용하는 것을 계속하지 못할 것입니다. 그 이유는 만약 트렁크로부터 당신의 브랜치로 재동기화를 시도하면, 머지 트래킹은 브랜치로 머지가 아직 되어 있지 않은 트렁크 수정의 재통합 버젼을 보게 될 것이고, 브랜치를 트렁크로 머지한 것을 브랜치로 다시 머지하려 들 것입니다. 이 방법은 새로운 브랜치를 트렁크에서 생성하고 다음 개발까지만 진행하기에 유용한 방법입니다.

 

Merge two different trees

이것은 재통합 방법의 보다 일반적인 케이스입니다. 이것은 서브버젼에 이렇게 요구하는 것이죠. "트렁크의 헤드 리비젼부터 브랜치에 헤드리비젼까지 얻어와서 필요한 수정을 추리고, 그 수정을 내 워킹 카피(트렁크의) 반영하라." 최종적인 결론은 트렁크를 정확히 브랜치처럼 본다는 것입니다.

 

만약 당신의 서버/레포지토리가 머지 트래킹을 지원하지 않는다면, 이것은 트렁크로 브랜치를 머지할 유일한 방법입니다. 또다른 것은 당신이 밴더 브랜치를 사용중이고, 새로운 밴더가 당신의 트렁크 코드에 넣은 수정을 머지할 필요가 있을 때 사용합니다. 보다 자세한 정보는 서브버젼 책의 밴더 브랜치 챕터를 읽어보세요.

 

4.20.1 Merging a Range of Revisions

Figure 4.45 The Merge Wizard - Select Revision Range

 

이 폼에서 필드에는 브랜치의 전체 폴더 URL이나 워킹카피에 카피하고자 하는 수정이 포함된 태그가 들어갑니다. 레포지토리 브라우져를 보기 위해 ...을 클릭할 수도 있고, 원하는 브랜치를 찾을수 있습니다. 이 브랜치 이전껄 머지를 하고 싶다면, 사용할 URL의 이전 히스토리 리스트를 불러 사용 할 수 있습니다.

 

Revision range to merge 필드에는 머지하길 원하는 리비젼의 리스트를 넣습니다. 여기서 하나의 리비젼만 넣을 수 있고, 콤마로 나눈 여러 리비젼 리스트나 -로 나눈 리비젼 범위 또는 이것들을 조합해 사용할 수 있습니다.

 

머지를 위해 Peg 리비젼을 명시하길 원한다면 리비젼의 끝에 Peg 리비젼을 추가합니다. 예) 5-7,10@3.

아래 예제에서 리비젼 5,6,7과 10을 머지하고, peg 리비젼 3개를 더할 겁니다.

 

중요

TortoiseSVN으로 명시된 리비젼 범위는 커맨드 라인 클라이언트와 비교해 중요한 차이가 있습니다. 이것을 상상하는 가장 쉬운 방법은 포스트와 팬스 패널을 함께 팬스로 생각하는 것입니다.

 

커맨드 라인 클라이언트에서 시점의 전후를 명시하는 2개의 "팬스 포스트"를 머지할 수정에 명시합니다.

 

TortoiseSVN에선 '팬스 패널'을 사용해 머지하기위해 수정 집합을 명시합니다. 이 이유는 로그 다이얼로그를 사용해 머지할 리비젼을 명시할때,각 리비젼에서 수정 집합으로써 나타나는 곳에서 명확하기 위해서 입니다.

 

만약 청크에서 리비젼을 머지하는 중이면, 서브버젼 책에서 보여진 방법은 100-200을 먼저 머지하고, 200-300을 다음에 머지하는 것입니다. TortoiseSVN에선 100-200을 이번에 머지하고, 201-300을 다음에 머지하게 됩니다.

 

이 차이는 메일링 리스트에서 뜨거운 논란을 가지고 있습니다. 우리는 커맨드 라인 클라이언트로 부터 이 차이가 있다는 것을 알고 있습니다. 그러나 우리는 우리가 구현한 방법이 많은 수의 GUI 유저들에게 더 쉽게 이해된다고 믿습니다.

 

필요한 리비젼의 범위를 선택하는 가장 쉬운 방법은 Show Log를 클릭하는 것입니다. 이것은 로그 커맨드에서 최근 수정을 보여줍니다. 만약 하나의 리비젼만 머지하길 원한다면, 단지 그 리비젼만 선택하면 됩니다. 여러개의 리비젼을 머지하길 원한 다면, Shift-Modifier를 보통 사용해 리비젼을 선택하면 됩니다. OK를 클릭하고 머지할 리비젼 넘버리스트가 나타날 것입니다.

 

워킹 카피를 밖에서 되돌려 수정을 머지하길 원한다면, 이미 커밋된 수정을 되돌리기 위해 리버트할 리비젼을 선택하고 리비젼 머지 박스 체크박스를 확실하게 하면 됩니다.

 

만약 이미 이 브랜치에서 어떤 수정이 머지 되었다면, 바라건데 수정을 커밋했을때, 로그 메세지에서 머지된 마지막 리비젼의 노트를 만들 수 있을 겁니다. 이 경우 로그 메세지를 추적하기 위해 워킹 카피의 Show Log를 사용 할 수 있습니다. 우리는 수정 집합으로 리비젼을 생각하는 것을 기억 하세요. 이 머지에 대해 시작 지점으로 마지막 머지의 끝 지점 이후 리비젼을 사용해야 합니다. 예를 들어 37에서 39까지 마지막에 머지했다면, 리비젼 40을 머지 시작 지점으로 사용합니다.

 

서브버젼의 머지 트래킹 특징을 사용한다면 서브버젼은 이미 머지한 리비젼이 기록되기 때문에 기억할 필요가 없습니다. 리비젼 범위를 블랭크로 남기면 머지되지 않은 모든 리비젼은 포함될 것 입니다.

 

좀더 이해하기 위해선 섹션 4.20.6 "머지 트래킹'을 읽어보세요.

 

머지 트래킹을 사용했을때, 로그 다이얼 로그는 이전 머지된 리비젼을 보여주는데, 공통의 최초 지점 보다 먼저 리비젼이 표시됩니다. 예를 들어 브랜치가 카피되기 이전은 회색으로써 표시됩니다. Hide non-mergeable revisions 체크박스는 머지가능한 리비젼만 보도록 그 리비젼들을 완전히 걸러내는 것을 허용합니다.

다른 사람이 수정을 커밋했고, HEAD 리비젼을 주의깊게 사용했다면, 당신이 마지막 업데이트 이후에 다른 사람이 커밋을 만든 리비젼을 참조하지 않을 수 있습니다.

Next 클릭은 섹션 4.20.4 "머지 옵션"으로 가세요.

4.20.2 재통합 브랜치

Figure 4.46 The Merge Wizard - Reintegrate Merge

특정 브랜치를 트렁크로 머지하기 위해선 당신은 트렁크의 워킹카피에서 머지 위저드를 시작해야만 합니다.

URL폼에는 브당신이 머지를 원하는 브랜치의 풀 폴더 URL을 입력합니다. 레포지토리 브라이져를 위해선 ...을 클릭할 수 있습니다.

재통합 머지를 적용하기 위해선 특정 상태가 있습니다. 먼저 서버는 반드시 머지 트래킹을 지원해야만 합니다. 워킹 카피는 depth infinite이여야만 합니다.(sparse checkouts은 안됩니다.) 그리고 로컬 수정과 변경된 아이템 HEAD에 비해 업데이트된 리비젼을 가지고 있지 않아야 합니다. 모든 트렁크의 모든 수정이 브랜지 개발동안 만들어져 브랜치에 머지되어 있거나 머지된것 처럼 표시되어야만 합니다. 머지할 브랜치 범위는 자동으로 계산될것입니다.

4.20.3 Merging Two Different Trees

 

Figure 4.47. The Merge Wizard - Tree Merge

특정 브랜치를 트렁크로 머지하려고 이 방법을 사용한다면 당신은 트렁크의 워킹 카피에서 머지 위저드를 시작할 필요가 있습니다.

From에 트렁크에 머지할 풀 폴더 URL을 입력합니다. 이것은 잘못된 말일수도 있습니다. 그러나 트렁크는 브랜치 수정을 더하길 원하는 곳을 가르키는 시작지점으로 기억하세요. ...을 클릭하면 레포지토리 브라이져를 사용할 수 있습니다.

To에선 특정 브랜치의 풀 폴더 URL을 입력하세요.

From리비젼과 To리비젼 필드 둘다 2개의 트리에서 동기화된 마지막 리비젼 번호가 들어갑니다. 당신이 어떤 커밋도 하지 않았다는 것을 확신하면 HEAD 리비젼을 사용할 수 있습니다. 만약 동기화 이후 다른 누군가가 커밋을 했다면, 최신 커밋 이후를 잃지 않게 해당 리비젼 번호를 사용합니다.

리비젼을 선택하기 위해 Show Log를 사용할 수 있습니다.

4.20.4 머지 옵션

위저드의 이 페이지는 머지 프로세스를 시작하기 이전에 당신을 어드밴스 옵션들로 이끕니다.  그냥 보통 기본 옵션을 사용할 수도 있습니다.

머지를 위해 사용할 뎁스를 명시할 수 있습니다. 당신의 워킹 카피 머지가 얼마나 진행해야할지를요.

기본 뎁스는 워킹카피이고, 뎁스 셋팅을 사용합니다. 그리고 이것은 거의 대부분 당신이 원하는 것입니다.

보통 당신은 파일의 히스토리를 고려해 머지하길 원하고, 수정은 공통 원본에 대해 머지되길 원할 것입니다.

때때로 레포지토리에 없는 관련 머지 파일이 필요할 수도 있습니다. 예를 들어 당신이 버젼1과 2를 서드파티 라이브러리에서 2개의 나눠진 디렉토리로 임포트 시킬수 있습니다. 버젼들이 로직적으로 연관되어 있어도, 서브버젼은 이것에 대해 알수가 없습니다. 왜냐하면 당신이 임포트한 타르볼만 볼수가 있기 때문입니다. 당신이 이 두 트리 사이에서 차이를 머지하길 시도한다면, 완전히 추가된 것에 따라 완전히 삭제된 것을 볼 수 있습니다. 서브버젼을 히스토리 기반 차이 보다 패스 기반 차이를 사용하기 위해선 Ignore ancestry box를 체크하세요. 이 주제에 대한 자세한 내용은 서브버젼 책의 Noticing or Ancestry를 읽어보세요.

라인 끝이나 공백 수정을 다루는 방법을 명시할 수 있습니다. 이 옵션은 섹션 4.10.2 "Line-end and Whitespace Options"에서 기술 됩니다. 기본 동작은 모든 공백과 라인 끝 차이를 실제 머지하는 수정과 같게 다룹니다.

Force the merge 체크박스는 로컬에서 수정됬거나, 버젼이 아닌데 삭제되 영향을 받게 되는 파일이 있을때 트리 컴플리트를 피하는데 사용합니다. 파일이 삭제되면 그것을 회복할 방법은 없습니다. 이것이 기본으로 이 옵션이 체크되지 않은 이유입니다.

머지 트래킹을 사용하고 머지할 리비젼에 체크하길 원하면, 여기에 실제로 행위 없이 오직 머지 체크박스에 기록을 체크할 수 있습니다. 이것을 하는 2가지 가능한 이유가 있습니다.  머지 알고리즘이 너무 복잡해서 손으로 수정을 코딩했으면 머지 트레킹 알고리즘이 이를 알도록 수정을 표시해야 합니다. 또다른 하나는 머지로 부터 특정한 리비젼을 막기를 원할때 입니다. 이미 머지 된것으로 표시되면 머지 트래킹 클라이언트에서 머지가 발생되는 것을 방지하게 됩니다.

이제 모든 것이 셋팅되면, Merge버튼을 클릭하기만 하면 됩니다. 만약 머지 진행을 시뮬레이션하는 Test Merge 결과를 보길 원한다면, 워킹 카피의 수정없이 할 수 있습니다. 이것은 실제 머지에서 수정되게될 파일 리스트와 충돌이 발생할지도 모르는 파일을 보여줍니다. 머지 트래킹은 머지 과정을 보다 복잡하게 만들기 때문에 총돌없이 머지가 완료되는지 보장하는 방법은 없습니다. 그래서 테스트 머지에서 파일이 충돌로 표시되도 어떤 문제가 없을수 있습니다.

머지 프로세스 다이얼로그는 리비젼 범위를 포함된 머지의 각 단계를 보여줍니다. 이것은 기대했던 것 보다 하나 이상의 리비젼을 가르킬수 있습니다. 예를 들어 당신이 123 리비젼의 머지를 요청하면 프로세스 다이얼 로그는 '머지 리비젼 122부터 123을 보여주게 됩니다. 이것을 이해하기 위해선 머지가 차이에 가까운 연관이라는 것을 기억할 필요가 있습니다. 머지 프로세서는 레포지토리의 2개 점 사이 차이 리스트가 보장되서 작업을 하게 됩니다. 그리고 워킹 카피에 이 차이를 적용합니다. 프로세스 다이얼 로그는 시작과 끝 지점을 단순히 보여주게 됩니다.

 

4.20.5. 머지 결과 리뷰하기

머지가 이제 완료했습니다. 머지를 살펴보고 예외를 눈여겨 보는건 좋은 생각입니다. 머지는 보통 상당히 복잡합니다. 컴플리트는 브랜치가 트렁크로 부터 멀어지게 되면 종종 발생합니다.

 

1.5 이전 서브버젼 클라이언트와 서버는 머지 정보를 저장하지 않았고, 머지된 리비젼은 수동으로 추적해야만 했습니다. 당신이 수정을 테스트했고  리비젼이 커밋되 올 때, 당신의 커밋 로그 메세지는 머지에 합쳐진 리비젼 넘버를 항상 포함하게 됩니다. 만약 당신이 다른 머지를 이후에 적용하길 원한다면 이미 머지가 무엇이 되었는지 알 필요가 있습니다. 당신이 하나 이상의 수정이 합쳐지길 원하지 않는 것을 원한다면요. 이것에 대한 보다 자세한 정보는 서브버젼 북 Best Practises for Merging 을 참조하세요.

 

만약 서버와 모든 클라이언트가 서브버젼 1.5 이상이면, 머지 추적 기능이 머지된 리비젼이 기록되고, 리비젼이 하나이상 머지되는것을 피할 수 있습니다. 이것은 매번 전체 리비젼 범위에서 간단하게 머지할 수 있고, 새로운 리비젼만 머지를 활성화 되는 것을 알게되어 당신의 삶을 단순하게 만듭니다.

 

브랜치 관리는 매우 중요합니다. 만약 당신이 브랜치를 trunk와 함께 최신으로 유지하길 원한다면, 자주 트렁크와 브랜치가 너무 멀어지지 않게 자주 머지하는 확신을 가져야만 합니다. 물론 아래 설명처럼 수정의 반복된 머지를 피해야만 합니다.

 

팁:

만약 트렁크로 브랜치를 머지했다면 트렁크는 그 브랜치의 모든 코드를 포함하게 됩니다. 그리고 그후 브랜치는 필요가 없습니다. 요구에 따라 레포지토리로 부터 삭제할 수 있습니다.

 

중요:

서브버젼은 파일과 폴더를 합칠 수 없고, 오직 폴더와 폴더, 파일과 파일만 할 수 있습니다. 만약 파일을 클릭하고 머지 다이얼로그를 오픈하면 다이얼로그에서 파일에 패스를 넣어야만 합니다. 만약 폴더를 선택하고 다이얼로그를 호출하면, 머지에 대한 폴더 URL을 명시해야만 합니다.

 

4.20.6 머지 추적

서브버젼 1.5는 머지 추적에 대한 기능이 도입됬습니다. 당신이 한 트리로 부터 다른 트리로 머지를 할때, 브랜치 넘버는 저장되고, 이 정보는 여러 다른 목적으로 사용될 수 있습니다.

 

- 당신은 같은 리비젼을 두번 머지할 위험을 피할 수 있게 됩니다.(반복된 머지 문제). 한번 머지한 리비젼은 표시되고, 범위내 포함된 리비젼은 스킵하게 됩니다.

 

- 브랜치를 트렁크로 머지할 때, 로그 다이얼로그는 트렁크 로그의 커밋된 부분을 보여줍니다. 좀더 수정을 추적하기 쉽게 합니다.

 

- 블레임 정보를 파일에서 볼 때, 머지한 사람이 아니라, 머지한 리비젼의  원 작성자를 보는 것을 선택할 수 있습니다.

 

- 머지를 수행하지 않고, 머지한 리스트에 있는 이미 포함되서 머지되지 않는 리비젼을 리비젼에 표시할 수 있습니다.

 

머지 추적 정보는 svn:mergeinfo 프러퍼티에 클라이언트에 의해 머지를 수행할 때 저장됩니다. 머지가 커밋되면 서버는 데이터베이스에 해당 정보를 저장합니다. 머지,로그, 블래임 정보를 요청할때, 서버는 알맞게 응답합니다. 프러퍼티를 작업한 시스템에 대해 당신은 서버, 레포지토리 그리고 모든 클라이언트를 업데이트 하도록 보장해야 합니다. 이전 클라이언트는 svn::mergeinfo 프러퍼티를 저장하지 않고, 이전 서버는 새로운 클라이언트에 요청된 정보를 제공하지 않습니다.

 

머지 추적에 대한 보다 자세한 정보는 서브버젼의 Merge tracking documentation을 참조하세요.

 

4.20.7 머지하는 동안의 충돌

머지는 항상 스무스하게 작동하지 않습니다. 다양한 범위를 머지한다면 때때로 충돌이 발생하며, 다음 범위를 머지하기 전에 충돌을 해결하고 싶을 겁니다. TortoiseSVN은 머지 컴플리트 콜백 다이얼로그를  보여줌으로써 당신이 이 프로세스를 통과하게끔 도와줍니다.

 

피겨 4.48 머지 컴플리트 콜백 다이얼로그

 

수정중 일부는 스무스하게 머지될 수 있습니다만, 다른 로컬 수정은 이미 레포지토리에 커밋된 수정과 충돌됩니다. 머지할 수 있는 수정은 모두 머지됩니다. 머지 컴플리트 콜백 다이얼로그는 충돌난 라인을 핸들링할 3가지 방법을 제공합니다.

 

1. 만약 머지에 바이러니 파일이 포함되 있으면, 이것의 충돌간 머징은 불가능합니다. 당신은 하나의 파일을 선택해야만 합니다. Prefer local을 선택하면 당신의 워킹 카피의 로컬 버젼을 우선으로 머지에 카피합니다. 또는 Prefer repository를 선택하면 레포지토리의 머지 소스로부터 파일을 가져옵니다.

 

2. 텍스트 파일들의 머지했을때, 먼저 2개 버튼은 일반적으로 충돌나지 않은 라인은 머지하는 것을 허용합니다만 충돌 난 곳에는 항상 하나의 버젼을 우선합니다. Prefer local을 선택하면 충돌 중 당신의 로컬 버젼을 선택합니다. 즉 머지 소스로 부터 들어오는 수정을 머지하기 이전에 이미 거기 있는 버젼을 우선합니다. Prefer repository는 총돌에서 레포지토리를 선택하게 됩니다. 즉 당신의 워킹 카피 위로 머지 소스가 오는 것을 우선합니다. 그러나 충돌은 종종 당신이 생각하는 것보다 많은 라인을 덮을 수 있으며, 예기치 않은 결과를 가져올 수 있습니다.

 

3. 일반적으로 당신은 충돌난 것을 보고 해결하는 것을 원할 것입니다. 이는 머지 툴에서 Edit Conflict 로 시작합니다. 당신은 결과에 만족하게 되면, REsolved를 클릭하세요.

 

3. 마지막 옵션은 해결을 미루고 계속 머지를 계속합니다. 남은 머지에서 현재 충돌난 파일의 해결을 무리거나 또는 모든 파일들을 미룰수 있습니다. 그러나 그 파일이 더 나아가 수정된 파일이면 머지는 완료가 불가능합니다.

 

당신은 이 상호적인 콜백을 원하지 않는다면, 머지 프로세스 다이어그램 머지의 non-interactive를 체크박스가 있습니다. 만약 이것이 머지할때 설정되어 있고, 머지에서 충돌이 나면, 파일은 머지한후, 충돌로 표시할 것입니다. 전체 머지가 끝난 후에는 충돌을 해결해야만 합니다. 설정되어 있지 않으면 파일이 충돌로 표시되기 이전에 당신은 머지하는 동안 충돌을 해결할 기회를 갇습니다. 이것은 복수의 머지를 하나의 파일에 적용하려 할때 유리합니다. 그 다음 머지는 영향을 받은 라인들과 독립적으로 성공할 수 있습니다. 그러나 머지하는 동안 커피를 마시러 나가지 못할 이유가 될수 있습니다. ;)

 

4.20.8 완료된 브랜치 머지

만약 다른 브랜치로 부터 트렁크로 머지하길 원한다면, 이때는 extended context menu의 TortioseSVN ->Merge reintegrate... 를 사용할 수 있습니다.(파일 위에 쉬프트키를 누르고 우클릭하세요)

 

Figure 4.49 The Merge reintegrade Dialog

 

이 다이얼로그는 매우 쉽습니다. 섹션 4.20.4 '머지 옵션'에서 설명한 것 처럼 머지에 대해 옵션을 설정할 수 있습니다. 나머지는 TortoiseSVN이 머지 트래킹을 사용해 자동으로 완료합니다.

 

4.20.9 해당 브랜치 유지관리

당신이 브랜치에서 새로운 기능을 개발할때, 기능 개발이 완료되면 재통합에 대한 정책을 감안하는 것은 좋은 생각입니다. 트렁크에서 같은 시간대에 다른 작업이 거의 다 되가는데, 브랜치 간 차가 매우 중요하다는 사실을 찾을지도 모릅니다. 그리고 머지는 악몽이 되겠지요.

 

기능의 연관성이 단순하고 개발이 길지 않을 경우는 간단한 접근을 취할 수 있습니다. 기능 개발이 완료할때 까지 나눠진 브랜치를 유지하고 트렁크에 수정을 머지합니다. 머지 위저드에서 간단히 브랜치 범위의 리비젼을  머지할 것입니다.

 

만약 기능개발이 길고, 트렁크에서 수정할 필요가 있다면, 당신은 브랜치 동기화를 유지할 필요가 있습니다. 이것은 정기적으로 트렁크의 수정사항을 브랜치로 머지하는 것을 의미합니다. 그래서 그 브랜치는 새로운 기능을 첨부해 트렁크의 모든 수정을 포함하게 됩니다. 동기화 과정은 리비젼 범위 머지를 사용합니다. 기능이 완료되면, 당신은 트렁크로 Reintegrate a branch나 Merge two different trees를 사용해서 머지할 수 있습니다.