Subversion 저장소의 분기 중 하나를 새 트렁크로 만드는 가장 좋은 방법은 무엇입니까?
전체 시스템에 대한 주요 재 작성이있었습니다. 사물이 이동, 재 작성, 교체, 제거, 이름이 변경되었습니다. 재 작성된 코드는 테스트를 거쳤으며 이전 트렁크를 대체 할 준비가되었습니다.
기본적으로 이전 메인 라인 (Trunk 5)에 태그가 지정되고 여기서 끝납니다. 재 작성된 브랜치 (Branch 6)는 새로운 메인 라인 (Trunk 7)이됩니다.
트렁크 (1)-> 트렁크 (2)-> 트렁크 (5)-> × +-> 새 트렁크 (7)
\ \ |
포크 병합 ???
\ \ |
+-> 분기 (3)-> 분기 (4)-> 분기 (6)-+
이전 'Trunk'에서 진행중인 모든 변경 사항은 이미 'Rewritten branch'에 통합되어 있습니다.
어떻게 할 수 있습니까?
답변:
svn move 를 사용 하여 이전 트렁크의 내용을 다른 곳으로 이동하고 나중에 브랜치의 이름을 trunk로 바꿉니다.
svn의 복사 및 이동은 파일 작업처럼 작동합니다. 이를 사용하여 저장소에서 항목을 이동 / 복사 할 수 있으며 이러한 변경 사항도 버전이 지정됩니다. "이동"을 "복사 + 삭제"로 생각하십시오.
[편집] Nilbus는을 (를) 사용할 때 병합 충돌이 발생할 것이라고 알려주었습니다 svn move.
나는 이것이 올바른 접근 방식이라고 생각합니다. 충돌이 발생하지만 신중하게 병합하면 데이터가 손실되지 않을 가능성이 있습니다. 그것이 당신을 괴롭 히면 Mercurial 또는 Git 과 같은 더 나은 VCS를 사용하십시오 .
이 목표를 달성하기 위해 svn move 명령을 사용하는 데 동의합니다.
나는 여기에있는 다른 사람들이 그것이 특이하다고 생각한다는 것을 알고 있지만, 나는 이것을 이렇게하는 것을 좋아합니다. 기능 분기가 있고 크게 수정 된 트렁크와 병합 할 준비가되면 일반적으로라는 이름의 새 분기에 병합합니다 <FeatureBranchName>-Merged. 그런 다음 충돌을 해결하고 병합 된 코드를 테스트합니다. 완료되면 트렁크를 태그 폴더로 이동하여 아무것도 잃지 않도록합니다. 마지막으로 <FeatureBranchName>-Merged트렁크 로 이동 합니다.
또한 이동을 할 때 작업 복사본을 피하는 것을 선호합니다. 다음은 명령 샘플입니다.
svn move https://SVNUrl/svn/Repo/trunk https://SVNUrl/svn/Repo/tags/AnyName
svn move https://SVNUrl/svn/Repo/branches/BranchName-Merged https://SVNUrl/svn/Repo/trunk
참고 : 1.5를 사용합니다.
최근에이 문제를보고 있었는데 매우 만족 스러웠던 해결책은
svn merge --ignore-ancestry trunk-url branch-url
내 트렁크의 작업 사본에.
이것은 변경 사항을 기록 방식으로 적용하려고하지 않습니다 (트렁크의 변경 사항 유지). 트렁크와 브랜치 사이에 단순히 "차이를 적용"합니다. 수정되지 않은 파일에서 사용자에게 충돌이 발생하지 않습니다. 그러나 분기에서 기록 정보를 잃게되지만 어쨌든 병합을 수행 할 때 발생합니다.
저장소 브라우저 도구를 통해 이러한 변경을 수행 할 것을 권장합니다.
작업 복사본을 통해 대규모 삭제 + 이동 작업을 시도하는 것은 작업 복사본을 종료하는 좋은 방법입니다. 작업 복사본을 사용해야하는 경우 각 삭제 또는 이동 작업 후 증분 커밋을 수행하고 각 커밋 후에 작업 복사본을 업데이트합니다.
@Aaron Digulla 및 @kementeus 솔루션은 실행 가능합니다. Subversion 1.4 리포지토리의 경우 복사 / 이동 작업으로 인해 향후 다른 리포지토리 구조로 마이그레이션하거나 리포지토리 분할이 어려울 수 있습니다.
1.5의 개선 사항에는 이동 / 복사 기록의 더 나은 해상도가 포함되어 있으므로 1.5 저장소에서는 문제가되지 않을 것입니다.
1.4 저장소를 들어, 내가 사용하는 것이 좋습니다 것 svnadmin dump및 svndumpfilter다음 같은 메커니즘을 트렁크에 지점을 이동, 다른 기존 트렁크의 움직임을 수행 할 수 있습니다. 두 개의 덤프 파일을 테스트 저장소에로드하고 확인한 다음 프로덕션으로 이동합니다.
물론 시작하기 전에 기존 저장소를 백업하십시오.
이는 이동 / 복사를 명시 적으로 기록하지 않고 기록을 보존하고 향후 재구성, 기록 보존을 더 쉽게 만듭니다.
편집 : 요청한대로 1.4 Red-Bean 책, Filtering Repository History 에서 1.4 동작에 대한 문서
또한 복사 된 경로로 인해 문제가 발생할 수 있습니다. Subversion은 이미 존재하는 경로를 복사하여 새 경로를 만드는 저장소에서 복사 작업을 지원합니다. 리포지토리 수명의 어느 시점에서
svndumpfilter제외 되는 일부 위치에서 포함 된 위치로 파일 또는 디렉터리를 복사했을 수 있습니다 . 덤프 데이터가 자급 자족하도록하려면svndumpfilter복사본에 의해 생성 된 모든 파일의 내용을 포함하여 새 경로의 추가를 계속 표시해야하며 필터링 된 덤프 데이터 스트림에 존재하지 않을 소스의 복사본으로 해당 추가를 나타내지 않아야합니다. 그러나 Subversion 저장소 덤프 형식은 각 개정에서 변경된 내용 만 표시하기 때문에 복사 소스의 내용을 쉽게 사용할 수 없습니다. 저장소에 이러한 종류의 복사본이 있다고 의심되는 경우 문제가되는 복사 작업의 소스로 사용 된 경로를 포함하여 포함 / 제외 된 경로 집합을 다시 생각할 수 있습니다.
이것은를 사용하는 마이그레이션 / 재구성에 적용됩니다 svndumpfilter. 지금 약간의 추가 작업으로 나중에 많은 추가 작업을 절약 할 수 있으며, svndumpfilter향후 마이그레이션 / 재구성을 위해 쉽게 사용할 수 있도록 유지함으로써 상대적으로 저렴한 비용으로 위험을 완화 할 수 있습니다.
위의 답변은 작동하지만 모범 사례는 아닙니다. 최신 svn 서버 및 클라이언트 트랙이 병합됩니다. 따라서 svn은 브랜치에 병합 한 수정 내용과 위치를 알고 있습니다. 이는 분기를 최신 상태로 유지 한 다음 다시 트렁크에 병합 할 때 많은 도움이됩니다.
그러나 어떤 버전의 Subversion을 사용하든 상관없이 브랜치의 변경 사항을 트렁크로 다시 가져 오는 모범 사례 방법이 있습니다. 이는 Subversion 매뉴얼 : Version Control with Subversion, 4 장. 분기 및 병합, 분기 동기화 유지에 설명되어 있습니다.
SVN에서는 정말 이상하고 비정상적인 구성입니다. 어쨌든 "좋은 습관"이 아니라고 생각하더라도 다음과 같이 할 수 있습니다.
행운을 빕니다