18

ローカルのSubversionczarとして、私はすべての人に、巨大なバイナリデータファイルではなく、ソースコードと非巨大なテキストファイルのみをリポジトリに保持するように説明します。おそらく、テストの一部である小さなバイナリファイル。

残念ながら私は人間と仕事をしています！誰かがいつか誤って800MBのバイナリハルクをコミットする可能性があります。これにより、リポジトリの操作が遅くなります。

前回チェックしたとき、リポジトリからファイルを削除することはできません。最新のリビジョンの一部ではないようにするだけです。誰かがその日付またはリビジョン番号のリポジトリの状態を思い出したい場合に備えて、リポジトリはモンスターを永遠に保持します。

そのモンスターファイルを本当に削除して、まともなサイズのリポジトリになってしまう方法はありますか？svnadminのダンプ/ロードを試しましたが、苦痛でした。

4

4 に答える 4

17

モンスターファイルをsvnリポジトリから完全に削除するには、svnadmin dump/loadを使用する以外に解決策はありません。（SVNブック：ダンプコマンド）

巨大なファイルがコミットされるのを防ぐために、フックスクリプトを使用できます。たとえば、誰かがリポジトリにコミットしようとするたびに「pre-commit」を実行するスクリプトを作成できます。スクリプトは、ファイルサイズまたはファイルタイプをチェックし、大きすぎるファイルまたは「禁止」タイプのファイルが含まれている場合、コミットを拒否する場合があります。

フックスクリプトのより一般的な使用法は、コミットにログメッセージが含まれていることを確認（コミット前）するか、コミットの詳細を電子メールで送信するか、新しくコミットされたファイルでWebサイトを更新することです。

フックスクリプトは、リポジトリイベントへの応答に応答して実行されるスクリプトです（SVNブック：フックの作成）。

于 2008-09-17T07:48:34.893 に答える
13

これに関するいくつかの追加情報は、ブログ投稿で見つけることができます: Subversion Obliterate, the missing feature

Karl Fogel が記事を大局的に説明しているコメントも必ず読んでください :-)

于 2008-09-18T21:34:40.610 に答える
3

コミットされてすぐにそれをキャッチできれば、svnadmin のダンプ/ロード手法はそれほど苦痛ではありません。誰かが誤ってリビジョン 3849 の gormundous-raw-image.psd をコミットしたとします。次のようにすることができます。

svnadmin dump /var/repos -r 1:3848 > ~/repos_dump

これにより、リビジョン 3848 までのすべてを含むダンプ ファイルが作成されます。その時点で、svnadmin create および svnadmin load を使用して、問題のあるコミットなしでリポジトリを再構成できます。注意点は、リポジトリのディレクトリ構造内で行った変更です。 -フック、シンボリックリンク、権限の変更、認証ファイルなど--古いディレクトリからコピーする必要があります。操作を完了するために使用できる bash セッションの残りの例を次に示します。

svnadmin create /var/repos-new
svnadmin load /var/repos-new < ~/repos_dump
cp -r /var/repos/conf /var/repos-new
cp -r /var/repos/hooks /var/repos-new
mv /var/repos{,-old} && mv /var/repos-new /var/repos

リポジトリの履歴が多いほど、これはより苦痛になると思いますが、機能します。

于 2008-09-17T17:04:48.490 に答える
1

HEAD リビジョンからファイルを削除すると、リビジョン間の差分のみが処理されるため、操作速度が低下することはありません。(もちろん、リポジトリのバックアップは負荷を処理する必要があります)。

于 2008-09-17T08:14:20.760 に答える