Subversion 제어하에있는 디렉토리가 있습니다. 병합 테스트를 위해 지점을 만들었습니다. 나는 파일을 가져 와서 트렁크의 줄 X를 "abc"로 수정하고 같은 줄 X를 그 지점에서 "def"로 수정했다. ,SVN 병합 질문
svn merge branchURL trunkURL .
그것은 그 줄 번호에서 "ABC"와 같은 내용으로 파일을 업데이트는 같은 줄 번호로 나에게 충돌을 포기하지 않았다 즉 :
그런 다음 분기 작업 디렉토리에서 내가 그랬어 svn update은 내가 같은 작업 디렉토리에서 그것을 수행하고 다른 누군가가 저장소에 "def"를 저질렀다면 나에게 줄 것이다.
그래서 svn merge은 병합 중에 내용을 대체 하나 충돌을 일으키지 않습니까?
그렇다면 주 트렁크에서 proj 디렉토리를 분기하는 이유는 트렁크와 분기의 변경 사항을 유지하기 위해 병합 할 수없는 경우 쓸모가 없습니다.
당신은 예,
svn merge branchUrl trunkUrl branchWorkingCopy
실제로 무엇을 실현 하는가? trunkUrl의 동일 branchUrl의 내용을 확인하기 위해 필요한 변화의 세트 밖으로
그림 :
여기 번역입니다. 이제 해당 변경 사항을 branchWorkingCopy에서 수행하십시오.
이 방법으로 병합하지 않아도됩니다. 그러나 branchWorkingCopy을 체크인하면 지점을 트렁크와 동일하게 만들 수 있습니다. 이는 거의 확실하지 않습니다.
svn merge -r100:103 trunkUrl branchWorkingCopy
그냥 지점에 트렁크에서 선택 변경을 복사하려면 복사 및 병합 명령의 다른 양식을 사용하려면 서브 버전을 변화를 이야기해야합니다
의미 : 트렁크에서 r100에서 r103으로 변경하는 데 필요한 변경 집합을 결정합니다. 해당 변경 사항을 (지점의) 작업 사본에서 수행하십시오. 이 "변경된 집합"은 r99에서 r100으로 변경하는 데 필요한 변경 집합으로 캡처되므로 r100의 변경 내용은 포함되지 않습니다. Subversion의 개정 범위는 반일입니다.
아직 읽지 않은 경우 fine manual을 읽는 것이 좋습니다.
그는 여전히 갈등을 겪을 수 있지만 (내가 한), 그렇지 않으면 당신의 대답은 틀린 것입니다. –
놀랍지 만, branchWorkingCopy에 커밋되지 않은 변경 사항이 없다고 가정합니다. 깨끗한 목적지와도 갈등을 겪었습니까? – bendin
사실이 답변은 논쟁의 순서가 잘못된 명령을 사용함에 따라 나의 모든 의구심을 분명히했습니다 ... – ashishsony
때문에 병합 및 이 충돌을 가져 오지하면서 SVN 병합 그냥 가 콘텐츠를 대체합니까?
음, 아니오. 나는 당신이 잘못한 것을 실제로 지적 할 수는 없지만, 병합 플래그는 업데이트와 충돌한다.
내가 누락되었을 수도 있지만 svn merge를 사용했을 때 제대로 작동하려면 수정 번호를 받아야했습니다. 당신이 개정 (100)에서 분기 (또는 마지막 병합) 경우
그래서, 트렁크는 200에서 현재, 그리고 당신은 분기 작업 디렉토리에 다음, 당신의 지점으로 트렁크 변경 사항을 병합 할 당신이 할 :
svn merge -r 100:200 trunkURL
그런 다음 충돌을 보게 될 것입니다. 문제를 해결하고 체크인하십시오. 트렁크 작업 디렉토리에서 트렁크로 다시 분기에서 병합하기 위해 비슷한 작업을 수행합니다.
-r없이 svn merge는 지정한 두 위치를 diff하고 해당 diff를 작업 디렉토리에 적용합니다. 그래서 나는 일어난 일이 갈등이 없다는 것입니다. 왜냐하면 당신의 작업 영역이 지점의 머리와 일치하기 때문입니다. 따라서 브랜치 헤드와 트렁크 헤드 간의 차이는 문제없이 작업 디렉토리에 적용될 수 있습니다. 이것은 당신이 원하는 것이 아닙니다 : 트렁크와 일치하도록 작업 디렉토리를 변경하는 것뿐입니다. 분기를 다시 변경하고 체크인 한 다음 프로세스를 반복하십시오. 만약 merge가 (트렁크에 있지 않기 때문에) 변경을 취소한다면, 나는 svn merge의이 형태에 대해 옳다. 그러나 나는 그것을 사용하지 않았다.
[편집 : SVN 버전 1.5 ... 이전] 그대로
작업 디렉토리와 나뭇 가지 당신이 차이를 설명해야 SVN에서 같은 일이 아니며, 짜증나. SVN은 업데이트 나 체크 인보다 원하는 브랜치 병합을 수행하는 데 더 많은 정보가 필요합니다. 왜냐하면 afaik는 브랜치가 어디에서 발생했는지를 자동으로 고려하지 않기 때문에 작업 디렉토리가 체크 아웃 된 곳을 항상 고려합니다. 그 이유는 확실합니다. 나는 그것이 무엇인지 확실하지 않습니다. 왜냐하면 svn copy는 단순히 브랜치 (branch)보다 많은 것들을위한 것이기 때문입니다.
[편집 ...하지만 조슈아 맥키 논 (Joshua McKinnon)의 답변에 따르면, 1.5에서 svn은 자동으로 원하는 것을 수행하는 적절한 분기 병합을 지원합니다.병합 할 URL을 지정하고 병합중인 작업 디렉토리에서 명령을 실행하십시오. 그러므로이 경우에는
svn merge trunkURL
으로 시도해보십시오. 충돌이 표시되어야합니다. 먼저 작업 디렉토리를 되돌릴 수도 있습니다.]
전복 1.5까지, 나는 이것이 항상 필요하다고 생각합니다. 이제 대상 workspce의 'svn merge sourceURL'명령은 병합중인 것으로 기록되지 않은 모든 버전을 Subversion의 메타 데이터에 병합합니다. –
좋은 하나, 고마워. 이제 당신은 그것을 언급합니다, 나는이 점에 관해서 1.5가 개선되었다는 것을 기억합니다. 그러나 1.5시에 나온 회사는 이미 올바른 버전 번호를 알아내는 스크립트를 이미 가지고 있었고 내가 떠날 때까지는 변하지 않은 것을 가지고있었습니다. –
나는 왜 내가 충돌을하지 못했는지에 대한 올바른 지적이 있다고 생각한다. 그러나 나는 나의 관찰을 더 게시하기 전에 월요일에 다시 시도해야 할 것이다. 응답 해 주셔서 감사합니다. – ashishsony
그래서 1) 분기 2) 수정 된 줄 X "abc"를 트렁크에 3) 분기 된 4) 수정 된 줄 X "분기"에서 5) 병합 5? X 축의 내용을 "abc"로 수정하기 전에 그 내용은 무엇입니까? –
내 사무실에서 버전 차이가있을 것 같아/내 클라이언트 svn 및 서버 svn, 내가 최근 1.5 svn 버전을 업그레이드하고 repos 존재하는 서버에서 발생하지 않았다 기억합니다. 그래서 내가 충돌을 얻지 못했다는 사실은 버전 차이의 결과 일 수 있습니다. – ashishsony