4

小さなファイルと大きなファイルの違いが原因で、Subversion リポジトリが大きくなってしまう理由がわかりません。

いくつかのテストで使用されるデータベースのコンテンツの zip ファイルがあります。テスト データの新しいバージョンをそれぞれ Subversion リポジトリに保存したいと考えています。

私はいくつかの実験を行い、data.zip の最近のいくつかのバージョンをチェックインして、リポジトリのサイズがどうなるかを調べました。圧縮されていないデータは約 150MB で、圧縮されて圧縮されたものは約 50MB です。リポジトリにチェックインされた data.zip ファイルの新しいバージョンごとに、リポジトリのサイズが約 50MB 増加します。私はそれがはるかに少ないと予想されるデルタの量だけ増加するべきだと思います.

Subversion は xdelta を使用して、圧縮された差分データを格納します。SVN がより適切に機能することを確認するための私の試みは、xdelta をダウンロードして、2 つのバージョンに大きな違いがないことを確認することでした。それはそう

xdelta3.0z.x86-64.exe -e -s v1_path\data.zip v2_path\data.zip v1v2_delta.file

約 3MB の v1v2_delta.file を作成しました。

[myrepo]\db\revs の SVN リポジトリを調べたところ、新しいリビジョンごとに大きなファイルが表示されます。

02/08/2011  11:12        57,853,082 4189
02/08/2011  11:40        51,713,289 4190
02/08/2011  11:46        52,286,060 4191

(4189、4190、4191 はファイル名です。)

圧縮せずにdata.zipを圧縮してみました。これは、SVN が保存するものに違いはありませんでした。一見すると、最初のリビジョンだけでなく、すべてのリビジョンに対して data.zip 全体の圧縮コピーを保存していると思います。FSFS バックエンドで SVN 1.6 を実行しています。

バイナリのコミットと、 SVNがどのようにデルタを格納するかについて、他にもさまざまなスタックオーバーフローの優れた回答があります。しかし、これらから、上記のケースでデルタが保存されていない理由がわかりません。xdelta がスタンドアロンで実行されているような小さな差分を取得できる場合、SVN も確実に取得できます-またはそうしないことを選択していますか?!

編集： tar（非圧縮）ファイルも試しましたが、SVNはそれらを効率的に保存していません。また、SVNが diffs を保存したばかりの別のリポジトリに、同じデータ形式 (ただし、はるかに小さい) の zip ファイルがあることもわかりました。

したがって、この質問の要約版は次のとおりです。SVN はバイナリ ファイルを効率的に格納できます。たとえば、わずかに異なる 10 個の CAD ファイルは、 1 のサイズのちょうど 1.2 倍です。SVN は、圧縮された zip ファイルを使用してスペース効率を高めることさえできます。しかし、明らかに、バイナリ ファイルでは常にスペース効率が良いとは限りません。

4

4 に答える 4

3

概要

Subversion は、圧縮に割り当てられるメモリの量が原因で、xdelta スタンドアロンよりも悪い場合があります。これは、バージョン 1.6 の時点で現在変更できないサブバージョンの動作です。

詳細

私は、subversion メーリング リストで、subversion リポジトリ ファイルが本来よりも大きく見える理由を尋ねました。

結論として、xdelta は、より多くのメモリを与えると、より小さなデルタを生成できるということです。

このスレッドで、同じ問題を抱えた別の例を読み返してください。

最近と 4 年前の Subversion メーリング リストのさまざまな人々の功績と感謝を込めて。

また、この問題を抱えていますか？

Subversion リポジトリによるディスク使用量を分析している場合は、スキップ デルタを理解し、このgrep DELTA トリックを使用して、デルタに使用されているベースを特定します。

そして、私のように、あなたが本当にバイナリファイルをリポジトリに保存したいと仮定すると、いくつかの回避策があると思います (どれも簡単ではありません!):

  1. サブバージョンのソース コードを変更し、xdelta メモリ ウィンドウを大きく設定して独自のコードをビルドします。
  2. あなたは xdelta-ing を所有していますか - デルタをソース管理にチェックインし、再構築のためのクレイジーなお尻のプロセスを持っています
  3. Git に移行 - 圧縮率が向上するはずです (勝手な憶測)
于 2011-08-09T19:08:08.207 に答える
1

圧縮アーカイブでファイルが追加または変更されると、圧縮ファイルのバイナリ コンテンツが大幅に変更される場合があります。アーカイブの特定の要素で変更が発生する可能性があり、圧縮されたファイル ファイルの大きな領域で大きな変更が発生しない可能性があると考えられます。ただし、通常の場合にそうなるかどうかは「運」の問題です (もちろん、これには本当の運はありませんが、それを達成するための計画は少し複雑です)。

これは、ファイルが追加または変更されるとシンボルの頻度が変化するため、Huffman (最も単純なものを挙げると) などのエントロピー エンコーディング アルゴリズムではごく普通のことです。これがアーカイブのコンテンツの先頭で発生すると、変更後のファイルのコンテンツ全体に深刻な影響を与える可能性があります。

于 2012-04-22T09:38:47.237 に答える
1

圧縮によってバイナリ ファイルの構成が完全に変更されるため、svn は巨大なデルタを格納する必要があると思います。圧縮ファイルの内容の数文字を変更するだけでも、大幅に変更される可能性があります。

バイナリをソース管理に保存することは一般的に悪い考えであり、別の方法を探すべきだと思います。

于 2011-08-02T19:39:42.813 に答える
-1

fsfsファイルシステムのバッキングを使用しましたか？私が覚えているように、それは毎回新しいコピーを保存します（それは圧縮されるかもしれませんが）。なぜSVNがバイナリファイルの差分を保存することを期待しているのですか？SVNはソースコード管理システム（テキストを意味します）であり、一般的なバイナリ管理システムではありません（ただし、バイナリの保存の場合ほど悪くはありません）。

于 2011-08-02T21:05:12.700 に答える