私は、SVN インストールをバージョン 1.5.6 から 1.7.6 に移行する責任を負っています。その一環として、両方のリポジトリのダンプ/ロード サイクルを行ったところ、たまたま奇妙なことに気付きました..
リポジトリの 1 つは 2 GB のファイルに「ダンプ」しますが、それをロードした後、約 23 GB のディスク領域を占有します。これは 1.5.6 の問題でもありましたが、アップグレードがこれに役立つことを期待していました。
問題のレポは、7500 個のファイル (以前は最大 12000 個) を含む単一のフォルダーと、別の 500 個程度のファイルを含むサブフォルダーが含まれているという点で、少し「奇妙」です。
この問題に関連している可能性があるようです: 350GB SVN リポジトリは、ブランチ/タグのような最も単純なタスクでも少なくとも 1MB のリビジョンを作成します
これについて今何ができるか非常に途方に暮れていますが、レポは現在とんでもないペースで成長しており、解決しない場合は再配置する必要があります. 私が避けたいと思っていた仕事。
まず、SVN には、BDB (バークレー DB) と FSFS (ファイル システム)の 2 つの異なるリポジトリ バックエンドがあります。リポジトリがディスク上にどのように存在するかは、この選択に依存し、通常、BDB は少し大きくなります。あなたはどれを使いますか？
FSFS を使用する場合は、シャーディングについて読む必要があります。変更をコミットすると、どんなに小さいものでも、ディスクによって設定された最小サイズ (通常は 2kb ～ 16kb) のファイルにコミットされます。これにコミットされているファイルの数を掛けると、非常に大きな数が得られます。良いニュースは、コマンドを実行してシャードを 1 つのファイルに圧縮できることです。
svnadmin pack /path/to/repository
これにより、ディスク上のサイズが大幅に改善される可能性があります。
または、スペースの問題は、あなたが言及したコミットごとの大量のファイルの問題である可能性があります。
いずれにせよ、ダンプ ファイルがリポジトリのサイズよりもはるかに小さい理由を尋ねます。ダンプ ファイルは、基本的にリポジトリで行われたすべてのコミットの形式の単一のファイルです。これは非常に簡潔な形式のリポジトリです (特に --deltas が使用されている場合)。これは単一のファイルに配置されるため、シャーディングの問題は回避されます。
以前の組織では、SVN を使用して擁護していました。最近、私は Mercurial DVCS (Hg とも呼ばれ、Git に似ています) に移行しました。一度スイッチを入れると、元に戻すことを考えるのは困難です。とにかく、リポジトリのサイズに関するSoftpediaからの引用は次のとおりです。
ディスク容量: Mozilla プロジェクトが SVN から Mercurial に移植されたとき (パフォーマンスは Git と非常に似ています)、ディスク容量の使用量は 12GB から 420MB に減少し、元のサイズの 30 分の 1 になりました。Git は同じストレージ アルゴリズムを使用することになっているため、ファイル サイズはほぼ同じ値になるはずです。
Hg または Git に切り替えた場合に何が起こるかを調査することをお勧めします。Softpedia の例のように劇的な場合は、管理者に Hg/Git を勧めることができます。