「そのようなリビジョンはありません」というサブバージョンのロードが失敗する

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

そこで起こることは、まず、必要なものを除外し、明らかな理由で空のリビジョンを削除し、番号を付け直します。これにより、適切な順序のリビジョンが提供されます。次に、プロジェクトのルートパスをドロップします。これは、私の場合はグループ/顧客の形式でした。なぜなら、意味のない新しいレポでは（レポジトリ自体がディスク上のグループ/顧客であるため）-これは最初の2 sedの

次に、名前のないディレクトリのインポートを削除します。1つはグループdirの上記の2つのsedの結果で、1つはgroup / customer dirの追加です。

最後に、著者を新しいものに変更するよう依頼しました。これは、プロパティ定義の長さを更新する必要があるため、少し注意が必要でした。

次に、それをロードして、ファイルシステムのパーミッションを修正します。apache用にコメントされた2つのchownに注意してください。場合によっては必要になります。結局、svnグループにApacheを追加することになりました。

現在、SVNリポジトリにマージしたことがないため、分割のためにそれらを処理する必要はありませんでした。あなたの場合、ソースリビジョンパスがインポートされず、エラーがリビジョン自体に不平を言ってもそれが見つからない理由が起こると想像します）。svnインポートファイルの経験則では、ある時点で参照されるものは、参照される前に既にインポートされている必要があります。そのため、必要な場合でも不要なものを除外したり、他の変更を反映するためにダンプファイルを正しく更新しなかった可能性があります。

マージされたソースパスに加えて、パラメータを使用した呼び出しなど、元のレポの関連する構造を提供する場合、私はあなたが逃したものを電話することができます。私のお金は合併の源泉です。

私は素晴らしいツールsvndumpsanitizerを使用しました。問題は、Subversionリポジトリの構造が複雑すぎることです。svndumpfilterがリビジョン10の場合、ユーザーが破棄したいノードが、リビジョン113で保持したい位置に移動するかどうかを知る方法がありません。 、リビジョン113では、必要なデータが既に破棄されているため、不要になります。

Svndumpsanitizerは異なる方法で動作します。どのノードを実際に保持する必要があるかを発見するために、ノードを数回スキャンします。保持するノードを決定した後、これらのノードのみを出力ファイルに書き込みます。最後に-必要に応じて、リポジトリを壊さないために保持する必要がある不要なノードを削除するコミットを追加します。