利用可能な RAM よりも大きなファイルを処理できる分散バージョン管理システム (git、bazaar、mercurial、darcs など) はありますか?
大規模なバイナリ ファイル (つまり、データセット、ソース ビデオ/画像、アーカイブ) をコミットできるようにする必要がありますが、ファイルの変更時にコミットして更新できるようにするだけで、それらを比較できる必要はありません。
私がこれを最後に見たのは約 1 年前ですが、明らかな候補はどれもこれを許可していませんでした。これらはすべて、速度のためにメモリ内で差分を取るように設計されているためです。これにより、大きなファイルのコードとその他のもの (「アセット管理」ソフトウェアまたは単に rsync とスクリプト) を管理するための VCS が残りました。これは、2 つのディレクトリ構造が重なっているとかなり見苦しくなります。
この質問をしてから 3 年が経ちましたが、バージョン 2.0 の時点で、Mercurial にはlargefiles 拡張機能が含まれており、私が最初に探していたものを実現しています。
largefiles 拡張機能を使用すると、クローンやプルに過剰な帯域幅を必要とせずに、Mercurial で圧縮できない大きなバイナリ ファイルを追跡できます。ラージファイルとして追加されたファイルは、Mercurial によって直接追跡されません。むしろ、それらのリビジョンはチェックサムによって識別され、Mercurial はこれらのチェックサムを追跡します。このように、リポジトリのクローンを作成したり変更セットを取得したりする場合、リポジトリの古いリビジョンにある大きなファイルは必要なく、現在のバージョンに更新するために必要なファイルのみがダウンロードされます。これにより、ディスク容量と帯域幅の両方が節約されます。
これをサポートする無料の分散バージョン管理システムはありません。この機能が必要な場合は、実装する必要があります。
git をオフにすることができます。彼らは、Linux カーネル開発ユース ケースの生のパフォーマンスに関心があります。巨大なバイナリ ファイルにスケーリングする際のパフォーマンスのトレードオフを彼らが受け入れることはまずありません。Mercurial については知りませんが、パフォーマンスのためにオペレーティング モデルをストレージ モデルに結合する際に、git と同様の選択をしたようです。
原則として、Bazaar は、ディスク上のストレージと実装戦略がユース ケースに最適化されたツリー/ブランチ/リポジトリ フォーマットを実装するプラグインを使用して、ユース ケースをサポートできるはずです。内部アーキテクチャがあなたをブロックし、有用なコードをリリースした場合、コア開発者が内部アーキテクチャの修正を支援してくれることを期待しています。また、Canonical と機能開発契約を結ぶこともできます。
特定の DVCS に関係なく、おそらく最も実用的なアプローチは、ハイブリッド システムを構築することです。巨大なファイル ストアを実装し、このストア内の BLOB への参照を選択した DVCS に格納します。
完全な開示: 私は Canonical の元従業員であり、Bazaar 開発者と密接に協力してきました。
はい、プラスチックSCMです。分散型であり、巨大なファイルを 4Mb のブロックで管理するため、いつでもそれらを完全にメモリにロードしなければならないという制限はありません。ここで DVCS のチュートリアルを見つけてください: http://codicesoftware.blogspot.com/2010/03/distributed-development-for-windows.html
BUP はあなたが探しているものかもしれません。これは、バックアップを行うための git 機能の拡張として作成されましたが、事実上同じことです。ファイルをチャンクに分割し、ローリング ハッシュを使用してファイル コンテンツをアドレス指定可能にし、効率的なストレージを作成します。
バージョン管理システムにバイナリファイルを保存するのは効率が悪いと思います。
バイナリ オブジェクトを参照するメタデータ テキストファイルをリポジトリに格納することをお勧めします。
配布する必要がありますか？おそらく、Subversionが新しい分散型VCSにもたらす大きな利点の1つは、バイナリファイルを処理する優れた機能です。