Subversion에서 트리 충돌이 발생하는 이유는 무엇입니까?

트렁크의 기능 분기가 있었고 트렁크에서 분기로 변경 사항을 주기적으로 병합하고 모든 것이 제대로 작동했습니다. 오늘 저는 지점을 트렁크로 다시 병합했으며 지점을 만든 후 트렁크에 추가 된 파일은 "트리 충돌"로 표시되었습니다. 앞으로 이것을 피할 수있는 방법이 있습니까?

나는 이것이 제대로 표시되지 않았다고 생각합니다.

게리가 준 링크를 읽는 해결책을 찾았습니다 (이 방법을 따르도록 제안합니다).

SVN 클라이언트 1.6.x로 작업 디렉토리 를 커밋 하는 트리 충돌을 해결하기 위해 요약하면 다음을 사용할 수 있습니다.

svn resolve --accept working -R .

.디렉토리가 충돌하는 위치 는 어디 입니까?

경고 : "작업 디렉토리 커밋"은 샌드 박스 구조가 커밋중인 구조임을 의미합니다. 예를 들어 샌드 박스에서 일부 파일을 삭제 한 경우 리포지토리에서도 삭제됩니다. 이것은 충돌 된 디렉토리에만 적용됩니다.

이런 식으로 SVN은 충돌을 해결하기 위해 SVN을 제안하고 ( --resolve) 현재 디렉토리 ( ) 에서 시작 하여 샌드 박스 ( --accept working) 내부의 작업 복사본을 재귀 적으로 ( -R) 수락합니다 ..

TortoiseSVN에서 오른쪽 클릭으로 "해결됨"을 선택하면 실제로이 문제가 해결됩니다.

Subversion 1.6은 디렉토리 수준에서의 충돌을 다루기 위해 트리 충돌을 추가했습니다. 좋은 예는 파일을 로컬로 삭제 한 다음 업데이트가 해당 파일에서 텍스트 변경을 시도하는 경우입니다. 또 하나는 편집중인 파일의 Subversion Rename이 추가 / 삭제 작업이므로 편집하는 파일입니다.

CollabNet의 Subversion 블로그에는 Tree Conflicts 에 대한 훌륭한 기사가 있습니다.

내 경험상 SVN은 폴더를 삭제할 때마다 트리 충돌을 일으 킵니다. 이유가없는 것 같습니다.

내 코드에서 작업하는 유일한 사람-> 디렉토리 삭제-> 커밋-> 충돌!

Git 으로 전환하기를 기다릴 수 없습니다 .

나는 명확히해야한다-나는 Subclipse를 사용한다 . 아마도 문제 일 것입니다! 다시, 나는 전환을 기다릴 수 없다 ...

이것이 당신에게 일어나고 있는지 모르겠지만 때로는 병합 할 잘못된 디렉토리를 선택하고 모든 파일이 완전히 잘 보이 더라도이 오류가 발생합니다.

예:

/ svn / Project / branches / some-branch / Sources를 / svn / Project / trunk로 병합 ---> 트리 충돌

/ svn / Project / branches / some-branch를 / svn / Project / trunk로 병합 ---> 확인

이것은 어리석은 실수 일지 모르지만, 좀 더 복잡하다고 생각하기 때문에 항상 분명하지는 않습니다.

여기서 일어나는 일은 다음과 같습니다. 트렁크에 새 파일을 만든 다음 지점으로 병합합니다. 병합 커밋에서이 파일은 브랜치에서도 생성됩니다.

브랜치를 다시 트렁크로 병합하면 SVN은 다시 동일한 작업을 시도합니다. 브랜치에서 파일이 생성 된 것을 확인하고 병합 커밋에서 트렁크에 파일을 생성하려고 시도하지만 이미 존재합니다! 트리 충돌이 발생합니다.

이를 피하는 방법은 특수 병합, 재 통합 을 수행하는 것 입니다. --reintegrate스위치로 이를 달성 할 수 있습니다 .

http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate 문서에서 이에 대해 읽을 수 있습니다 .

그러나 가지를 트렁크에 다시 병합 할 때 기본 수학은 상당히 다릅니다. 기능 분기는 이제 복제 된 트렁크 변경 사항과 개인 분기 변경 사항의 혼잡이므로 복사 할 간단한 연속적인 수정 범위가 없습니다. --reintegrate 옵션을 지정하면 Subversion에게 분기에 고유 한 변경 사항 만 신중하게 복제하도록 요청합니다. (실제로 최신 트렁크 트리와 최신 분기 트리를 비교하여이를 수행합니다. 결과 차이는 정확히 분기 변경 사항입니다!)

분기를 다시 통합 한 후에는 분기를 제거하는 것이 좋습니다. 그렇지 않으면 트렁크에서 분기까지 다른 방향으로 병합 할 때마다 트리 충돌이 계속 발생합니다. (앞에서 설명한 것과 정확히 같은 이유로)

이 문제를 해결할 방법이 있지만 시도한 적이 없습니다. 이 게시물에서 읽을 수 있습니다 : v1.6의 Subversion 브랜치 재 통합

이것은 동일한 버전의 클라이언트를 사용하지 않아서 발생할 수 있습니다.

동일한 저장소에 버전 1.5 클라이언트와 버전 1.6 클라이언트를 사용하면 이러한 종류의 문제점이 발생할 수 있습니다. (나는 방금 물렸다.)

파일 근처에서 편집 / 삭제 / come하지 않았기 때문에 의미가없는 트리 충돌이 발생하면 merge 명령에 오류가있을 가능성이 높습니다.

일어날 수있는 일은 이전에 현재 병합에 포함 된 많은 변경 사항을 이미 병합 한 것입니다. 예를 들어 트렁크에서 누군가 파일을 편집 한 후 나중에 이름을 바꿉니다. 첫 번째 병합에서 편집을 포함시킨 다음 두 번째 병합에서 편집과 이름 바꾸기 (실제로 제거)를 모두 포함하면 트리 충돌이 발생합니다. 그 이유는 이전에 병합 된 편집이 사용자 자신의 편집으로 나타나기 때문에 제거가 자동으로 수행되지 않기 때문입니다.

적어도 1.4 리포지토리에서 발생할 수 있습니다 .1.5에 도입 된 병합 추적이 여기에 도움이되는지 확실하지 않습니다.

오늘까지, 적어도 3 개월 전부터 지점을 트렁크에 다시 병합하려고 할 때 ( TortoiseSVN 1.11 사용 ) 수백 번의 트리 충돌이 발생했습니다 . BTW를 기반으로했는지 여부 2004 년 v1 이후로 TortoiseSVN을 사용해 왔으며, 항상 브랜치를 다시 통합하는 데 사용했습니다. 최근에 무슨 일이 있었을 것 같아요?

그래서 오늘 저는이 간단한 실험을했는데이 미친 갈등을 일으키는 것이 무엇인지 알게되었습니다.

1. 나는 트렁크 @ 393을 포크했다;
2. 수십 개의 파일을 임의로 수정하고 새 파일을 만들었습니다.
3. 나는 커밋했다. 이제 @ 395 (동료가 394에서 자신의 작업을 수행하도록 분기했습니다).
4. 그런 다음 지점을 트렁크에 다시 통합하려고 시도했지만 테스트 만했습니다. 마법사에서 TortoiseSVN의 권장 사항에 따라 : "모든 개정을 병합하려면 (재 통합) 상자를 비워 두십시오". 이를 위해 트렁크 폴더를 마우스 오른쪽 버튼으로 클릭하고 "/ path / to / branch에서 TortoiseSVN> 병합"을 선택 하고 대화 상자에 표시된대로 rev 범위를 비워 두었습니다 .

토론 : (첨부 파일 참조)

무엇의 모든 개정 ...? 약간은 내가 아는 한 클라이언트가 참조 된해야 " 대상의 모든 버전! (트렁크)", 등, 해당 분기를 재 통합의 과정에서, 나는 "병합 개정 1-HEAD"를 언급을 보았다! 세상에 불쌍한 악마, 당신은 여기서 당신의 죽음에 빠지고 있습니다. 그 지점은 339 년에 태어났습니다. 하나님을 위해서 출생 증명서를 읽을 수 없습니까?

해결:

1. 위즈가 조언 한 것에 반하여, 분기의 모든 개정판을 포함하는 범위를 지정하십시오! 따라서, 394-HEAD ;
2. 이제 병합 테스트를 다시 실행하고 시가를 얻습니다. ( ).

도덕 : 나는 그들이 왜 버그를 고치지 않았는지 알 수 없습니다. 그것이 버그이기 때문에 죄송합니다. 시간을내어 그들과 함께보고해야합니다.

내 특정 문제는 아마도 귀하의 문제와 관련이 없지만 오늘도이 문제를 겪었습니다. 파일 목록을 검사 한 후, 내가 한 일을 깨달았습니다. 한 어셈블리에서 다른 어셈블리의 파일을 일시적으로 사용하고있었습니다. 나는 그것에 많은 변경을하고 SVN 기록을 고아하고 싶지 않기 때문에 내 지점에서 다른 어셈블리의 폴더에서 파일을 옮겼습니다. 이것은 SVN에 의해 ​​추적되지 않으므로 파일이 삭제 된 다음 다시 추가되는 것처럼 보입니다. 결국 트리 충돌이 발생합니다.

파일을 다시 이동하고 커밋 한 다음 분기 를 병합 하여 문제를 해결했습니다 . 그런 다음 나중에 파일을 다시 옮겼습니다. :) 그것은 트릭을하는 것처럼 보였다.

나는 비슷한 문제가 있었다. 실제로 나를 위해 일한 유일한 것은 다음과 함께 충돌하는 하위 디렉토리를 삭제하는 것입니다.

svn delete --force ./SUB_DIR_NAME

그런 다음 작업 사본의 다른 루트 디렉토리에서 다시 복사하십시오.

svn copy ROOT_DIR_NAME/SUB_DIR_NAME

그런 다음

svn cleanup

과

svn add *

마지막 경고가 표시 될 수 있지만 무시하고 마지막으로 경고하십시오.

svn ci .

나는이 같은 문제가 있었고이 지침을 사용하여 병합을 다시 실행하여 해결했습니다 . 기본적으로 SVN의 "2-URL 병합"을 사용 trunk하여 히스토리 및 트리 충돌에 대해 크게 신경 쓰지 않고 지점의 현재 상태 로 업데이트 합니다. 114 트리 충돌을 수동으로 수정하지 않아도됩니다.

그것이 역사를 보존하고 싶은지 확실하지 않지만, 제 경우에는 가치가 있습니다.

때때로 발생하는 시나리오 :

릴리스 브랜치를 생성 한 트렁크가 있다고 가정합니다. 트렁크에서 일부 변경 (특히 "some-dir"디렉토리 작성)을 수행 한 후 나중에 릴리스 분기로 병합 할 기능 / 수정 브랜치를 작성합니다 (변경 사항이 충분히 작고 릴리스에 기능 / 수정이 중요하기 때문에). .

trunk -- ... -- create "some-dir" -- ...
     \                                  \-feature/fix branch
      \- release branch

그런 다음 기능 / 수정 지점을 릴리스 지점으로 직접 병합하려고하면 디렉토리가 기능 / 수정 지점에 없어도 트리 충돌이 발생합니다.

svn status
!     C some-dir
      >   local missing or deleted or moved away, incoming file edit upon merge

따라서 기능 / 수정 지점을 병합하기 전에 "some-dir"디렉토리를 작성한 기능 / 수정 지점을 작성하기 전에 트렁크에서 수행 된 커밋을 명시 적으로 병합해야합니다.

git에서는 필요하지 않으므로 종종 잊어 버립니다.