"그런 개정 없음"으로 서브 버전로드 실패


18

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을 나타내는 것입니다!

이 파일을로드하려면 어떻게해야합니까?

감사!


복잡한 항목 ( "덤프 및 필터"다음에 "가져 오기")이 실패하면 더 간단한 것을 먼저 시도하십시오 ( "덤프", "가져 오기"). 나는 단지 전체 저장소를 마이그레이션했으며 그 과정이 쉬워졌습니다.
Dirk Eddelbuettel

고마워, 더크 그래도이 리포지토리를 분리해야합니다.
Harlan

"덤프, 가져 오기. 손으로 줄임, 다시 덤프. 가져 오기 2 차 덤프"를 수행하십시오. ?
Dirk Eddelbuettel

내가 빠진 것이 아니라면 SVN이 그렇게 작동한다고 생각하지 않습니다. 덤프 파일 및 svndumpfilter 사용을 줄여야합니다. 그리고 우리는 가능한 한 역사를 유지하고 싶습니다.
Harlan

3
왜 git 또는 mercurial로 마이그레이션하고 동일한 단계에서 기존 SVN을 제거하지 않습니까?
vonbrand

답변:


1

이런 종류의 분할을 여러 번 수행했습니다. 필터를 사용하는 방법과 덤프 파일에서 처리하는 작업에 따라 달라집니다. 개인적으로 프로젝트 경로 옆의 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, 플러스 매개 변수를 사용하여 통화 관련 구조를 제공하는 경우, 나는 할 수있다 당신이 놓친 무슨 전화를 할 수있을. 내 돈은 합병의 소스에 있습니다.


1

나는 훌륭한 도구 svndumpsanitizer를 사용했다 . 문제는 서브 버전 저장소 구조가 너무 복잡하다는 것입니다. svndumpfilter가 개정 10에있을 때, 사용자가 폐기하고자하는 노드가 개정 113에서 유지하고자하는 위치로 이동 될 것인지 알 수있는 방법이 없습니다. 113 개정판에서는 이미 필요한 데이터를 버렸기 때문에 폐기됩니다.

Svndumpsanitizer는 다른 방식으로 작동합니다. 실제로 유지해야하는 노드를 찾기 위해 노드를 여러 번 스캔합니다. 유지할 노드를 결정한 후에는이 노드 만 출력 파일에 씁니다. 마지막으로-필요한 경우 저장소를 손상시키지 않기 위해 보관해야하는 원치 않는 노드를 삭제하는 커밋을 추가합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.