SVN 하위 디렉토리에 대한 커밋과 병합이 유해하다고 생각하십니까?

Question

우리는 주요 SVN 프로젝트 루트 안에 여러 개의 큰 서브 프로젝트를 가지고 있습니다.
릴리스 브랜치로 작업 할 때 내 서브 프로젝트 만 커밋하고 병합합니다. 주로 더 빠르기 때문에. (the section called “Common Branching Patterns”에 설명 된대로) 수명이 긴 릴리스 지점에 대한

• 만의 루트에 병합을 수행

  그러나, 동료는이 reference to merging subdirectories in Version Control with Subversion (일명는 "SVN 도서")를 지적 분기가 아니라 하위 디렉토리에 있습니다.

불행히도, 이것은 경고의 범위입니다. 링크 된 섹션은 설명을 제공하지 않습니다.

릴리스 분기에 유해한 SVN 하위 디렉토리를 커밋하고 병합합니까?
수명이 짧은 기능 분기는 어떻게됩니까?

Answer 1

하나의 가능한 설명은 변경 세트의 일부를 잊어 버릴 수 있다는 것입니다.

체크 아웃 한 하위 디렉터리 외부의 표지 파일을 병합하는 변경 집합이 있으면 해당 파일을 병합하는 것을 잊어 버릴 가능성이 항상 있습니다. 예를 들어

, 당신은 트렁크에이 같은 커밋이있는 경우 :

r5 | rich | 2009-04-16 22:22:46 +0200 (Thu, 16 Apr 2009) | 2 lines 
Changed paths: 
    M /trunk/subdir1/main.c 
    M /trunk/subdir2/main.c 

Change some stuff 

그리고 당신은 다음 지점에서 디렉토리 subdir1의 체크 아웃을 "안정적"다음과 같이 R5를 변경 세트를 병합 할 수 있습니다 : 다시 가서 로그를 보면

$ svn co http://example.com/svn/branches/stable/subdir1 
$ cd subdir1 
$ svn merge -c 5 http://example.com/svn/trunk/subdir1 . 
--- Merging r5 into '.': 
U main.c 
$ svn ci -m"Merged r5 from trunk" 

그러나 이것은 단지, 여전히 개정 5. 나쁜의 절반을 병합합니다, 지금이 표시됩니다 :

$ svn log -g http://example.com/svn/ 
... 
------------------------------------------------------------------------ 
r5 | rich | 2009-04-16 22:22:46 +0200 (Thu, 16 Apr 2009) | 2 lines 
Changed paths: 
    M /trunk/subdir1/main.c 
    M /trunk/subdir2/main.c 
Merged via: r6 

Change some stuff 

전체 커밋을 병합 한 것처럼 보입니다. 사실 커밋을 병합 한 것 같습니다. 물론 r6은 stable 브랜치에서 오직 하나의 파일 만 변경되었음을 보여줍니다.

------------------------------------------------------------------------ 
r6 | rich | 2009-04-16 22:28:16 +0200 (Thu, 16 Apr 2009) | 1 line 
Changed paths: 
    M /branches/stable/subdir2 
    M /branches/stable/subdir2/main.c 

Merge revision 5 from trunk 

누군가가 변경 세트의 일부만 병합되고 나머지는 수행해야한다는 것을 기억하거나 주목해야합니다. 하위 디렉토리 병합을 사용하지 않으면이 문제가 발생하지 않습니다.

실제로 이전 커밋을 모두 병합하지 않으려는 경우가 있으며 위의 시나리오는 의도 한대로입니다. 이 경우 의도를 설명하는 커밋 메시지를 추가하는 것이 가장 좋습니다.

Answer 2

커밋에 문제가 없어야하지만 SVN에서 병합되는 항목과 병합되지 않은 항목을 병합합니다.

따라서 나는 (SVN에 의해 ​​비교되는 데이터 세트 크기와 관련하여) 미래의 병합을 단순화하기 위해 루트에서 병합하기를 원한다고 가정합니다.

Answer 3

1.5 이전의 Subversion 버전의 경우 하위 디렉토리를 병합하면 나머지 복잡한 디렉토리 트리가 나중에 병합됩니다. 디렉토리를 병합 한 경우 svn은 해당 디렉토리의 모든 변경 사항을 다른 분기에 적용하기 만하면됩니다.이미 서브 디렉토리를 병합 한 다음 기본 디렉토리를 병합하려고 시도한 경우, 서브 디렉토리의 모든 변경 사항은 대상 분기에 이미 있습니다 (이전에 병합 한 이후). Svn은 이제 이러한 변경 사항이 이전 병합에서 발생했는지 여부를 알지 못했지만 하위 디렉토리를 병합하려고 할 때 "방해가되는"것들이 있다는 것을 보았습니다. 이로 인해 많은 충돌이 발생했습니다.

이 문제를 방지하려면 이전에 병합하지 않은 디렉토리 만 병합해야하므로 전체 프로세스가 훨씬 복잡해졌습니다. 이미 합병 된 하위 디렉토리의 수정 버전을 정확히 기억하고 나머지 디렉토리/수정 버전의 나머지 변경 사항 만 적용해야했습니다. 혼란 스러울 수 있습니다. 항상 전체 지점을 병합하면 훨씬 쉽게 만들 수 있습니다. 현재 버전의 Subversion은 이전의 병합을 내부적으로 추적하므로 이러한 문제를 피할 수 있습니다.

하위 디렉토리를 위임하는 데는 문제가 없습니다. svn의 경우 이는 저장소의 일반적인 글로벌 리비전 일뿐입니다. 그 리비전에서는 하나의 하위 디렉토리에만 변경 사항이 있지만 svn의 경우 다른 커밋과 마찬가지로 전체 저장소의 새 버전입니다.

Answer 4

또 다른 이유는 루트에만 병합하면 저장소의 폴더/파일에 설정 될 svn : mergeinfo 속성 수가 제한된다는 것입니다.