大きなバイナリファイルと1TBを超えるリポジトリのバージョン管理？
soomanyother すでに関連する質問があるので、このトピックをもう一度考えて申し訳ありませんが、私の問題を直接カバーするものはありません。
私が探しているのは、2つの単純な要件のみを処理できる優れたバージョン管理システムです。
- 大きなバイナリファイル（> 1GB）を保存する
- 1TBを超えるリポジトリをサポートします（はい、TBです）
どうして？次の大規模なOS展開のために数千のソフトウェアアプリケーションを再パッケージ化する過程にあり、それらのパッケージがバージョン管理に従うことを望んでいます。
これまでのところ、SVNとCVSの使用経験はありますが、大きなバイナリファイル（いくつかのMSIまたはCABファイルは1GBを超える）での両方のパフォーマンスには満足していません。また、今後2〜5年で予想されるデータ量に合わせて拡張できるかどうかもわかりません（私が言ったように、推定> 1TB）
それで、何かお勧めはありますか？私は現在、SVN外部モジュールとGitサブモジュールも調べていますが、それはソフトウェアパッケージごとにいくつかの個別のリポジトリを意味し、それが私たちが望むものかどうかはわかりません。
バージョン管理システムはソースコード用であり、バイナリビルド用ではありません。バイナリファイルのバックアップには、標準のネットワークファイルサーバーバックアップテープを使用することをお勧めします。ただし、ソースコード管理を使用している場合は、いつでも任意のバージョンのバイナリを再構築できるため、ほとんど不要です。バイナリをソースコード管理に入れようとするのは間違いです。
あなたが本当に話しているのは、構成管理として知られているプロセスです。数千の固有のソフトウェアパッケージがある場合、開発、テスト、リリース、顧客ごとのリリースなどのすべての構成（ビルド）を管理する構成マネージャー（ソフトウェアではなく人;-)）が必要です。 。
Boar 、「写真、ビデオ、その他のバイナリファイルの簡単なバージョン管理とバックアップ」をご覧ください。巨大なファイルや巨大なリポジトリを簡単に処理できます。
古い質問ですが、Perforceは多くの大企業で使用されており、特にゲーム開発会社では、多数の大きなバイナリファイルを含むマルチテラバイトのリポジトリが使用されていることを指摘する価値があります。
（免責事項：私はPERFORCEで働いています）
- 大きなバイナリファイル（> 1GB）を保存する
- 1TBを超えるリポジトリをサポートします（はい、TBです）
はい、それはApacheSubversionが完全にサポートする必要があるケースの1つです。
これまでのところ、SVNとCVSの使用経験はありますが、大きなバイナリファイル（いくつかのMSIまたはCABファイルは1GBを超える）での両方のパフォーマンスには満足していません。また、今後2〜5年で予想されるデータ量に合わせて拡張できるかどうかもわかりません（私が言ったように、推定> 1TB）
最新のApacheSubversionサーバーとクライアントは、このような量のデータを問題なく制御でき、完全に拡張できます。さらに、開発者が同じプロジェクトで作業している複数のサイトがある場合にパフォーマンスを向上させるさまざまなリポジトリレプリケーションアプローチがあります。
私は現在、SVN外部モジュールとGitサブモジュールも調べていますが、それはソフトウェアパッケージごとにいくつかの個別のリポジトリを意味し、それが私たちが望むものかどうかはわかりません。
svn:externals大規模なバイナリまたはマルチテラバイトプロジェクトのサポートとは何の関係もありません。 Subversionは完全にスケーリングし、単一のリポジトリで非常に大きなデータベースとコードベースをサポートします。しかし、Gitはnotではありません。 Gitでは、プロジェクトを複数の小さなリポジトリに分割して分割する必要があります 。これは多くの欠点と一定のPITAにつながるでしょう。そのため、Gitには、問題の痛みを軽減しようとするgit-lfsなどのアドオンが多数あります。
本当に VCSを使用する必要がある場合、svnはリポジトリ全体を作業コピーにコピーする必要がないため、svnを使用します。ただし、ファイルごとにクリーンコピーがあるため、ディスク容量の重複が必要です。
これらの量のデータを使用して、ドキュメント管理システムを探すか、（低レベルで）定義された入力プロセスで読み取り専用のネットワーク共有を使用します。
2017年5月の更新：
Gitは、 GVFS（Git仮想ファイルシステム）の追加 を使用して、事実上、任意のサイズの任意の数のファイルをサポートできます（Windowsリポジトリ自体から開始： " で最大のGitリポジトリ惑星 "（350万ファイル、320GB）。
これはまだ> 1TBではありませんが、そこで拡張できます。
GVFSで行われた作業は、上流で（つまり、Git自体に）ゆっくりと提案されますが、それはまだ進行中の作業です。
GVFSはWindowsに実装されていますが、まもなくMac（Office for Macを開発しているWindowsのチームが要求するため）およびLinuxで実装されます。
2015年4月
Gitは、実際にはラージデータの実行可能なVCSと見なすことができ、 Git Large File Storage（LFS） （GitHubによる、 2015年4月）。
git-lfs （git-lfs.github.comを参照））は、それをサポートするサーバーでテストできます： lfs-test-server （または直接github.com自体で）：
メタデータはgitリポジトリにのみ保存でき、大きなファイルは他の場所に保存できます。
「広域ファイル共有」向けの製品を提供している会社がいくつかあります。大きなファイルをさまざまな場所に複製できますが、ロックメカニズムが分散されているため、どのコピーでも1人で作業できます。人が更新されたコピーをチェックインすると、それは他のサイトに複製されます。主な用途はCAD/CAMファイルやその他の大きなファイルです。 Peer Software（http://www.peersoftware.com/index.aspx）およびGlobalSCAPE（http://www.globalscape.com/）を参照してください。
これは古い質問ですが、考えられる答えの1つは https://www.plasticscm.com/ です。それらのVCSは、非常に大きなファイルと非常に大きなリポジトリを処理できます。数年前に私たちが選んだとき、彼らは私の選択でしたが、経営陣は私たちを他の場所に押しやった。
ファイルシステムにアクセス可能なスナップショット と単一のインスタンスストア/ ブロックの組み合わせを提供するNASデバイス）に依存するだけで、はるかに良い場合があります。レベルの重複排除 、説明しているデータの規模を考えると.。
（質問には.cabファイルと.msiファイルについても記載されています。通常、選択した CIソフトウェア にはビルドのアーカイブの方法があります。 。それはあなたが最終的に求めているものですか？）
バージョン管理システムに付属する特典（変更ログ、簡単なrssアクセスなど）は、単純なファイル共有には存在しません。
バージョニングメタデータ機能のみを気にし、実際には古いデータを気にしない場合は、VCSにデータを保存せずにVCSを使用するソリューションが許容できるオプションである可能性があります。
git-annex が最初に頭に浮かんだのですが、 git-annexではないもの ページから、他にも似ているがまったく同じではない選択肢があるようです。
私はgit-annexを使用していませんが、説明とウォークスルーから、あなたの状況でうまくいくように思えます。