web-dev-qa-db-ja.com

Subversionのロードが「そのようなリビジョンなし」で失敗する

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 doesがダンプファイルに存在し、問題なくインポートされました。リビジョン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
19
Harlan

私はこのような分割を何度も行ってきました。それはすべて、フィルターの使用方法と、その後のダンプファイルでの処理に依存すると思います。個人的には、プロジェクトパスの横にある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つは上記の2つのsedがグループディレクトリに、もう1つはグループ/顧客ディレクトリが追加された結果です。

最後に、私はそれを新しいものに変更するように作者に歌いました。プロパティ定義の長さを更新する必要があるため、これも少しトリッキーでした。

次に、それをロードして、ファイルシステムの権限を修正します。 Apacheの2つのコメント付きのchownに注意してください。必要な場合もあります。結局、Apacheをsvnグループに追加してしまいました。

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

マージされたソースパスを含む元のレポの関連する構造と、パラメーターを使用した呼び出しを提供すると、私は可能性があります逃した。私のお金は合併の元にあります。

2
ciuly

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

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

2
ALex_hha