22

簡単な方法で消去機能を実装するためのシェルスクリプトを作成することを考えていました（外部的には、提案された方法を使用しますが、自動化されています）。

これが私が念頭に置いていたことです：

クライアント上

  1. svn list -R > file-list.
  2. grep のようないくつかの方法で file-list をフィルタリングして、一連のgrep XXX file-list>>files-to-delete.
  3. files-to-deletescp を使用してサーバーに転送します。

サーバー上

  1. リポジトリをダンプしますsvnadmin dump /path/to/repos > repos-dumpfile。これもバックアップとして保持できます。
  2. 「files-to-delete」の単語ごとにダンプ ファイルをフィルタリングし、次のようにします。cat repos-dumpfile | svndumpfilter exclude $file > new-dumpfile
  3. 新しいリポジトリを作成し、新しいファイルをそこにロードしますsvnadmin create new-name; svnadmin load new-name < new-dumpfile

これは機能しますか？どうすれば失敗しますか？他のアイデアはありますか？

4

4 に答える 4

7

はい、そのスクリプトは機能します。しかし、通常、それほど多くのファイルを消去することはありません。通常、obliterate は機密情報を誤ってコミットした場合にのみ必要です。

非常に多くのファイルに対して obliterate を使用してもよろしいですか?

于 2009-02-18T14:23:39.370 に答える
6

cat new-dumpfile | svndumpfilter exclude $file > new-dumpfile危険な例だと思います。new-dumpfile は完全には処理されず、その内容はおそらく失われますよね?

以下のコメントから: new-dumpfile は確実に失われます。これは、シェルがコマンドを開始する前であっても、それを上書き (長さをゼロに切り詰める) するためです。

于 2009-03-19T20:29:21.140 に答える
4

同様の、しかし少し複雑な要件がありました。過去に数百回のリビジョンがあり、いくつかの非常に大きな (>1GB) サンプル データ ファイルがリポジトリにコミットされました。その後、それらは移動され、最終的に HEAD から削除されました。ただし、それらはまだ改訂履歴に残っていたため、リポジトリが非常に大きくなりました。svn list -Rファイルが作業コピーに表示されなくなったため、 使用できませんでした。

ただし、svn listリビジョン引数を指定できます。大きなファイルがいつチェックインされたのか正確にはわかりませんでしたが、リビジョン 2000 以降であることはわかっていました。ファイル名のリストもありました。そこで、単純なループと uniq を使用して my を生成しましたfiles-to-delete:

cd $working_copy
for rev in {2000..2437}; do
    svn ls -R -r$rev | grep -f ~/tmp/big-file-names >> ~/tmp/file-paths;
done
cat ~/tmp/file-paths | sort | uniq > ~/tmp/files-to-delete
cd ~/tmp
# You should inspect "files-to-delete" to see if it looks reasonable!
cat dumpfile | svndumpfilter exclude `cat files-to-delete` > dumpfile.new
于 2010-12-16T01:15:35.667 に答える
0

異なるリビジョンで同じパスを持つファイルはどうなりますか? たとえば、 をコミット/trunk/fooし、名前を に変更してから/trunk/bar、消去したい別のものをコミット/trunk/fooします。今の歴史を失いたくない/trunk/bar。おそらくペグのリビジョンsvndumpfilterをサポートしていますか？

于 2010-01-25T12:37:43.003 に答える