svndumpfilter から奇妙な結果が得られます。多くのブランチに散らばっているリポジトリ内の 2 つの特定のファイルの 24 のインスタンスを消去する必要があります。次のように文書化されているようにコマンドを実行しています：
例えば
type dumpfile | svndumpfilter exclude foo1/bar.dat foo2/bar.dat > filtered_dumpfile
ただし、フィルタリングされたダンプ ファイルは、期待どおりにすべてのノードを削除するのではなく、2 つのノードのみを削除しているようです。2 つのダンプ ファイルで svndumptool diff を使用してこれを確認し、レポを再構築した後、除外されたファイルがまだ存在しています。
リポジトリ内のすべてのパスを見つけるために svnlook ツリーを使用したため、これらのファイルのインスタンスを見逃していないと確信しています。また、先頭のスラッシュがコマンドとダンプ ファイルで一致していることを確認しました。
誰にもアイデアはありますか？
質問に関連するApache Subversion FAQ エントリが最近更新され、リポジトリ履歴をフィルタリングできる新しいアプローチが追加されました。svndumpfilter複雑なリポジトリ履歴のフィルタリングは、アプローチよりも少し便利かもしれません。
リポジトリ履歴から除外する必要があるパスへの読み取りアクセスを拒否するパスベースの承認規則をsvnsync構成した後、ツールを使用してリポジトリを複製できます。
とは異なりsvndumpfilter、svnsyncは読み取り不能なソース パスを使用したコピー操作を通常の追加に自動的に変換します。これは、コピー操作に関連する履歴をフィルタリングする必要がある場合に役立ちます。
次のようにしてみてください。おそらく役立つでしょう。
type dumpfile | svndumpfilter exclude foo1/bar.dat | svndumpfilter exclude foo2/bar.dat > filtered_dumpfile
またはこの方法：
svndumpfilter exclude `cat filterlist.txt` < old.dump > new.dump
消去する必要があったファイルは、履歴の最後のチェックインでした。そのため、svnadmin dump を使用して、壊れたリビジョンの前のすべてのリビジョンのダンプを取得できました。
これは、このページで説明されている内容と似ています: http://robmayhew.com/delete-parts-of-subversion-history/
リビジョン 8195 でのチェックインの誤りを取り除く必要があったため、次のように実行しました。
svnadmin dump /path/to/current/repo -r0:8194 > svn.dump
svnadmin create /path/to/new/repo
svnadmin load /path/to/new/repo < svn.dump
これは機能しましたが、チェックアウトした作業コピーに 8195 からの情報がまだ含まれていました。私の作業コピーがサーバーに存在しないと思っていたバージョンなので、更新しようとするとエラーが発生しました。
リポジトリのバージョンを 8195 に戻すには、ミニチェックアウトを実行してどこかで些細な変更をチェックインする必要がありました。その後、不正なチェックインの影響を受けたファイルを削除した後、作業コピーをクリーンアップして更新することができました。これは、Linuxでsvnを使用して機能しました。
同僚が Windows で svn を使用しており、Tortoise の svn はこのリポジトリの修正に非常に苦労しました。どうやら、最新リビジョンの独自の内部キャッシュを保持しており、作業コピーを更新すると、キャッシュから「不良」リビジョン ファイルが復元されます。すべてをもう一度チェックアウトし、新しい作業コピーを作成して正しくする必要があると思います。
ファイルにすべてのプレフィックスを追加し--targets FILE、個別の exclude|include の代わりにオプションを使用できます