大部分がバイナリ ファイルの大規模なセットを管理するために推奨されるバージョン管理システムは何ですか? このセットには数千のファイルが含まれており、合計で約 8 GB になり、時間の経過とともに大きくなります。
GIT を試してみたところ、多くのバイナリ比較を実行するのがやや遅いことがわかりました。何か間違った設定をしたのでしょうか?
大部分がバイナリ ファイルの大規模なセットを管理するために推奨されるバージョン管理システムは何ですか? このセットには数千のファイルが含まれており、合計で約 8 GB になり、時間の経過とともに大きくなります。
GIT を試してみたところ、多くのバイナリ比較を実行するのがやや遅いことがわかりました。何か間違った設定をしたのでしょうか?
バージョン管理は別の名前で知られる傾向があります...ソース管理またはソースコード管理。名前自体は、それらが何のために構築されているかを正確に示唆しています: ソースコード - つまり、比較的小さな数の比較的小さなテキストファイルです。ほとんどのシステムは、さまざまな程度の成功で、大きなバイナリの大きなリポジトリも処理できます (または、少なくとも処理できるはずです)。
バージョン管理ツールには主に 3 つのタイプがあり、バージョン管理の保存に関しては、それぞれにさまざまなトレードオフがあります。しかし、大規模なバイナリの大きなリポジトリがある場合、これらの設計上の決定が成否を分ける可能性があります。
CVS や Subversion などの編集/マージ/コミット システムでは、この問題をうまく解決できません。これらのタイプのシステムでは、サーバーからコードを取得すると、作業ディレクトリにファイルが作成され、読み取り/書き込み可能になります。さらに、クライアントは、これらのファイルをローカルで変更したかどうかを判断するためのメカニズムを保存します。これは、サーバー上に存在するファイルの内容のハッシュであるか、編集されていない「ベースライン」ファイルのコピーである可能性があります。ファイルシステムで何が変更されたかを判断したい場合、バージョン管理クライアントは作業ディレクトリとベースラインを比較して、編集したファイルを通知します。
これらのタイプのシステムは、複数 GB のファイルを含む複数 GB のリポジトリにうまく拡張できない傾向があります。一部のツールは、使用パターンに十分注意すれば問題ない場合があります。たとえば、UI フロントエンドを回避し、代わりにチェックインするパスを明示的に提供することで、これらのツールの範囲を制限できる場合があります (作業ディレクトリ全体。)
さらに、ベースライン ファイル全体を使用するツールを選択すると、リソース用に 8 GB、ベースライン ファイル用にさらに 8 GB の 2 倍のディスク領域が必要になります。
git や mercurial などの分散バージョン管理システムも、ここで最高のパフォーマンスを発揮する可能性は低いでしょう。DVCS ツールは、集中編集/マージ/コミット システムとは根本的に異なる履歴モデルを持っていますが、ほとんどのツールは、作業ディレクトリの状態を判断したい場合に、ディレクトリ内のファイルを比較して何が変更されたかを確認するという点で似ています。
ここでも、必要なディスク容量が増えます。分散システムはリポジトリのコピーをローカルに保存するため、リポジトリには少なくとも作業フォルダーと同じ容量が必要です。これは最良のシナリオであり、システムが「浅い」履歴をサポートしていると想定しています。ファイルのすべての履歴バージョンが保存されるわけではありません。
一部の DVCS ツールには、バイナリまたは「大きなファイル」モードまたはプラグインがあり、大きなファイルはローカル リポジトリではなく中央サーバーに配置されます。この種のハイブリッド アプローチには、特に大きなファイルが常に必要なわけではない場合に、間違いなくメリットがあります。そうしないと、集中型バージョン管理システムのすべての複雑さと DVCS のすべての複雑さが組み合わさった状況に陥る可能性があります。
Team Foundation Server や Perforce などのチェックアウト/編集/チェックイン システムは、おそらくこれに最も適したバージョン管理システムです。これらのタイプのシステムでは、サーバーからコードをフェッチすると、ファイルが作業ディレクトリに作成され、読み取り専用に設定されます。これは、これらのファイルの編集を開始するときにツールに指示する必要があるためです。この時点で、クライアントはファイルを読み取り/書き込みに設定します。クライアント (またはサーバー) は、行った変更のリストを維持します。編集が完了したら、サーバーにチェックインできます。
これらのタイプのシステムは、非常に大きな (数 GB) リポジトリや非常に大きな (数 GB) ファイルがある場合に有利です。変更や差分ファイルの作業フォルダーを調べる必要がないからです。
システムによっては、どちらのモードでも機能する場合があることに注意してください。たとえば、TFS 2012 は既定で編集/マージ/コミット モデル ( 「ローカル ワークスペース」と呼ばれます) を使用しますが、チェックアウト/編集/チェックイン モデル ( 「サーバー ワークスペース」と呼ばれます) を明示的に使用するように作成できます。
(注、ここではEric Sink の用語を借りましたが、彼がバージョン管理システムに関する本を書いたことを考えると、これらは適切に信頼できるものだと思います。)
マルチGBファイルの大きなリポジトリが単なるランダムデータではなく、グラフィックやオーディオである場合、バージョン管理システムを完全に避けて、そのために特別に設計されたデジタルアセット管理ツールを目指すのが最善かもしれません目的。
これらのツールの一部 (Quark Publishing System や K4 など) は出版部門を対象としており、一部 (Adobe VersionCue など) はグラフィック デザインやイラストレーション部門を対象としています。これらのツールの一部 (Alienbrain など) には、Visual Studio プラグインも含まれており、グラフィックスやオーディオの作業を行い、コードを記述するゲーム開発スタジオを引き付けようとしています。
あなたがたまたまゲーム開発の仕事をしている場合は、この質問に対する適切な回答がゲーム開発サイトにいくつかあります。