Subversion 저장소를 마이그레이션하는 방법을 배우려고하는데 이해가되지 않는 문제가 발생합니다. 내가 사용했습니다 svndumpfilter
하위 프로젝트를 분할하고, 어떤 경로 접두사를 제거했습니다. 수백 개의 커밋이 이제 올바르게 가져 오지만 다음과 같은 오류가 발생합니다.
<<< Started new transaction, based on original revision 19190
* editing path : branches/features/DynamicSource ... done.
* editing path : branches/features/DynamicSource/src/build.properties ... done.
* editing path : branches/features/DynamicSource/src/client/default.htm ...done.
* editing path : branches/features/DynamicSource/src/client/js/AdHocController.js ... done.
* editing path : branches/features/DynamicSource/src/client/js/Report.js ... done.
svnadmin: E160006: No such revision 19098
* adding path : branches/features/DynamicSource/src/client/js/Enums.js ...
이제 덤프 파일로 이동하여 개정판 19190 및 19098을 봅니다. 우선, 개정 본 19098 이 덤프 파일에 존재하며 문제없이 가져 왔습니다. 개정판 19190은 병합입니다. 19190 년 안에 마지막 파일의 정보가 있는데, 이는 문제를 일으키는 것으로 보입니다 :
Node-copyfrom-rev: 19100
Node-copyfrom-path: trunk/src/client/js/Enums.js
Text-copy-source-md5: 2db7f8d9c0ba4750d88ce0722731aad6
Node-path: branches/features/DynamicSource/src/client/js/Enums.js
Node-action: add
Text-copy-source-sha1: 8f930509f8dbc17c5e82cd40aa5a76454d3d812c
Node-kind: file
Content-length: 0
혼란스럽게도 수정본 19100이이 필터링 된 파일에 없습니다. 그러나 오류는 19100을 나타내는 것이 아니라 19098을 나타내는 것입니다!
이 파일을로드하려면 어떻게해야합니까?
감사!
답변
이런 종류의 분할을 여러 번 수행했습니다. 필터를 사용하는 방법과 덤프 파일에서 처리하는 작업에 따라 달라집니다. 개인적으로 프로젝트 경로 옆의 svn 사용자를 변경하고 개정 번호를 변경해야했습니다. 수행 할 수있는 것을 볼 수 있도록 여기 내 스크립트의 관련 부분이 있습니다.
grp=$cust_group
usr=$cust_customer
svndumpfilter include $grp/$usr --drop-empty-revs --renumber-revs <$repo_dump > $repo_dump.$usr
sed -e "s/Node-path: $grp\/$usr/Node-path: /" <$repo_dump.$usr >$repo_dump.$usr.fixed1
sed -e "s/Node-copyfrom-path: $grp\/$usr/Node-copyfrom-path: /" <$repo_dump.$usr.fixed1 >$repo_dump.$usr.fixed2
sed -e "/Node-path: /{ N; N; N; N; N; N; s/Node-path: \nNode-action: add\nNode-kind: dir\nProp-content-length: 10\nContent-length: 10\n\nPROPS-END//}" <$repo_dump.$usr.fixed2 >$repo_dump.$usr.fixed3
sed -e "/svn:author/{ N; N; s/svn:author\n.*\n$svn_usr_from/svn:author\nV $svn_usr_len\n$svn_usr_to/}" <$repo_dump.$usr.fixed3 >$repo_dump.$usr.fixed4
svnadmin load $repo_dir/$cust_group/$cust_customer --ignore-uuid < $repo_dump.$usr.fixed4
chown svn:svn -R $repo_dir/$cust_group/$cust_customer
#chown apache $repo_dir/$cust_group/$cust_customer/db/txn-current
#chown apache $repo_dir/$cust_group/$cust_customer/db/current
# apache is in svn group so the above 2 are not needed
chmod -R g+rw $repo_dir/$cust_group/$cust_customer
무슨 일이 일어나는가 먼저, 필요한 것을 걸러 내고, 명백한 이유로 빈 개정을 삭제하고 번호를 다시 매 깁니다. 이것은 좋은 순서의 수정을 제공합니다. 그런 다음 내 경우에는 그룹 / 고객 형태의 프로젝트의 루트 경로를 삭제합니다. 왜냐하면 새로운 리포지토리에서는 의미가 없습니다 (대신 리포지토리는 디스크의 그룹 / 고객입니다).
다음으로, 이름이 지정되지 않은 디렉토리의 가져 오기를 제거합니다. 하나는 그룹 dir에 대해 위의 2 개의 sed에서 생성 된 것이고 하나는 그룹 / 고객에 대한 추가입니다.
마지막으로 저자에게 새 것으로 바꾸라고 했어요. 이것은 속성 정의의 길이를 업데이트해야하기 때문에 조금 까다 롭습니다.
그런 다음 파일 시스템 권한을로드하고 수정합니다. 아파치에 대한 2 개의 주석 처리 된 chown을 참고하십시오. 경우에 따라 필요할 수도 있습니다. 나는 결국 svn 그룹에 아파치를 추가하게되었습니다.
이제 SVN 저장소에 합병하지 않았으므로 분할을 처리 할 필요가 없었습니다. 귀하의 경우, 소스 개정 경로를 가져 오지 않았으므로 오류가 개정 자체에 불평하더라도 경로를 찾지 못하는 이유가 있다고 생각합니다. svn 가져 오기 파일의 경험상 규칙은 한 지점에서 참조되는 모든 것을 참조하기 전에 이미 가져 왔어 야한다는 것입니다. 따라서 원하는 경우에도 원하지 않는 것을 필터링하거나 덤프 파일을 올바르게 업데이트하여 다른 변경 사항을 반영하지 않았을 수 있습니다.
병합 된 소스 경로를 포함하여 원래의 repo, 플러스 매개 변수를 사용하여 통화 관련 구조를 제공하는 경우, 나는 할 수있다 당신이 놓친 무슨 전화를 할 수있을. 내 돈은 합병의 소스에 있습니다.
답변
나는 훌륭한 도구 svndumpsanitizer를 사용했다 . 문제는 서브 버전 저장소 구조가 너무 복잡하다는 것입니다. svndumpfilter가 개정 10에있을 때, 사용자가 폐기하고자하는 노드가 개정 113에서 유지하고자하는 위치로 이동 될 것인지 알 수있는 방법이 없습니다. 113 개정판에서는 이미 필요한 데이터를 버렸기 때문에 폐기됩니다.
Svndumpsanitizer는 다른 방식으로 작동합니다. 실제로 유지해야하는 노드를 찾기 위해 노드를 여러 번 스캔합니다. 유지할 노드를 결정한 후에는이 노드 만 출력 파일에 씁니다. 마지막으로-필요한 경우 저장소를 손상시키지 않기 위해 보관해야하는 원치 않는 노드를 삭제하는 커밋을 추가합니다.