4

我正在开始一个游戏开发项目，我和我的团队将使用 Mercurial 进行版本控制，我想知道有什么更合适的方式来存储游戏的二进制资产。基本上，我有两个选择：

  1. Mercurial 2.1 有largefiles 扩展名，但我不太了解它。似乎它可以解决“存储库膨胀”问题，但不能解决二进制合并冲突问题。

  2. 将二进制资产作为子存储库保存在 SVN 结帐中。这样我们可以锁定文件进行编辑并避免合并冲突，但我真的很想避免使用 2 个版本控制系统（尤其是我不太喜欢的一个）。

我没有想到的任何见解/建议或其他选择？

4

2 回答 2

1

正如您推测的那样，大文件将满足您的需求。对于合并二进制文件，如果您的文件类型存在合并工具，您可以设置一个合并工具。像这样的东西：

[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

但总的来说，使用源代码控制工具合并非文本内容总是很痛苦。数字资产管理应用程序的存在是为了减轻这种痛苦，但它们不是去中心化的，也不是很令人愉快的工作。

于 2012-02-10T02:00:54.490 回答
1

您是正确的，大文件扩展名将避免使存储库膨胀。发生的情况是您只下载了您正在检出的修订版所需的大文件。因此，如果您有一个 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。

于 2012-02-10T09:17:53.687 回答