私はゲーム開発プロジェクトと私のチームを開始しており、バージョン管理に Mercurial を使用する予定です。ゲームのバイナリ アセットを保存するより適切な方法は何かと考えていました。基本的に、2 つのオプションがあります。
Mercurial 2.1 にはlargefiles 拡張子がありますが、私はそれについてあまり知りません。「リポジトリの肥大化」の問題は解決するようですが、バイナリマージの競合の問題は解決しません。
バイナリ アセットを SVN チェックアウトにサブレポとして保持します。このようにして、編集のためにファイルをロックし、マージの競合を回避できますが、2 つのバージョン管理システム (特にあまり好きではないシステム) を使用する必要は避けたいと考えています。
私が思いもよらなかった洞察/アドバイス、またはその他のオプションはありますか?
largefiles 拡張機能がリポジトリの肥大化を回避することは間違いありません。何が起こるかというと、チェックアウトしているリビジョンに必要な大きなファイルのみをダウンロードするということです。したがって、50 MB のファイルがあり、10 回大幅に編集されている場合、バージョンはサーバー上で 500 MB を占める可能性があります。ただし、hg updateダウンロードする場合は、そのリビジョンに必要な 50 MB のバージョンのみをダウンロードします。
largefiles 拡張機能がマージに役立たないことも正しいです。実際、マージ手順を完全にスキップし、次のようなプロンプトのみを表示します。
largefile <some large file> has a merge conflict
keep (l)ocal or take (o)ther?
通常のマージ機構を使用する機会はありません。
ロックを行うには、私がクライアント用に書いたロック拡張機能を使用できます。彼らは、人々が簡単にマージできないファイルで作業する文書部門のためにそれを望んでいました。これは基本的に、Mercurial を Subversion と同様の集中型システムに変えます。ロックは中央リポジトリのファイルに保存され、クライアントは実行時と実行hg locks前にこのリポジトリに接続しますhg commit。
あなたが推測したように、大きなファイルはあなたが必要とすることをします。バイナリをマージするために、ファイル タイプに対応するマージ ツールが存在する場合は、マージ ツールを設定できます。このようなもの：
[merge-tools]
mymergetool.priority = 100
mymergetool.premerge = False
mymergetool.args = $local $other $base -o $output
myimgmerge = SOME-PROGRAM-THAT-WILL-MERGE-IMAGES-FOR-YOU
[merge-patterns]
**.jpg = myimgmerge
**.exe = internal:fail
ただし、一般に、ソース管理ツールを使用してテキスト以外のものをマージするのは常に面倒です。デジタル資産管理アプリケーションは、その負担を軽減するために存在しますが、分散化されていないか、操作するのが非常に快適ではありません.