使用UDK进行游戏开发的版本控制系统？

Question

我们的团队正在考虑使用虚幻开发工具包制作游戏，我们正在寻找版本控制解决方案。

我一直偏爱分散的VCS，如Git和Mercurial，并将其用于我的所有个人项目。 虽然我听说过使用这些系统进行游戏开发的问题，但它们并不适合大二进制文件。

Subversion似乎是一个很好的解决方案，但我过去根本没有使用它，所以我真的不知道它提供了什么。

Answer 1

您可以毫无问题地使用Mercurial或Git。 我不知道为什么@TomTom在没有提供任何关于原因的提示的情况下以这种方式说明。

当然，您必须管理每个游戏开发（电影，纹理，地图等）附带的各种二进制文件。 但是这两种软件都有办法处理它们。

水银

Mercurial有各种扩展来处理大文件，特别是二进制文件。

从版本2.0开始， 大文件扩展包含在Mercurial中，您无需下载任何其他内容即可使用它。 文件不直接存储在存储库中，但Mercurial会跟踪每个变更集所需的文件版本，因此您可以在需要时使用正确的文件下载游戏的精确版本。

在2.0之前，主要使用了两个扩展：

1. Bfiles扩展 ，用作2.0中新扩展的基础
2. Bigfile扩展 ，在我的观点中比其他两个更复杂一点

混帐

我不太熟悉Git处理大文件的可能性，但我知道存在各种解决方案。 这篇文章应该给出一些好的指示： 使用git管理大型二进制文件

我听说很多关于git-annex的好消息。

SVN

我已经将SVN与大文件一起使用，并且我没有比Mercurial（没有扩展名）更好地管理它们的印象。

如果你决定使用扩展来管理Mercurial / Git的大文件，那么Subversion在功能方面就落后了。

结论

关于保持二进制文件版本与源同步的问题，bot Mercurial和Git扩展可以很好地处理这个问题。

每个版本的二进制文件都存储在一个单独的集中目录（Mercurial术语中的largefile store ）中，当dev克隆存储库或更新到特定的变更集时，只从该存储中下载所需的文件 。

您甚至可以将同一商店用于各种存储库！

将文件添加到商店或更新文件的过程对开发人员来说几乎是透明的，因此例如对于长学习曲线没有问题。

总而言之，我真的不明白为什么Git或Mercurial没有完成任务，没有其他答案给出任何真正的理由。

在我看来，大型游戏公司坚持使用较旧的工具，因为更改需要时间，当您付费购买时，您会使用它！ 有多少公司仍在使用VSS或CVS，因为层次结构不会听到任何其他内容？ 上个月我们刚刚迁移到TFS（来自VSS）我正在工作......

Answer 2

我坚持用Git。 存储大型二进制文件可能会导致丢失的内容，您可以通过团队协作获得更多收益。 您将更新，更改，合并代码，而不仅仅是存储二进制文件，DVCS可以更好地处理这些问题。

Answer 3

Hq（Mercurial）2.0支持大文件很棒。

以前它是LargefilesExtension ，但是从版本2.0开始，这是与核心一起分发的。

Answer 4

大型游戏工作室通常使用http://www.perforce.com/ （说实话，我不知道为什么。）

SVN也是一个不错的选择，但与Git和Mercurial相比，它有点过时了。

无论如何，为什么要在存储库中放置大型二进制文件？ 您肯定希望为所有已编译的二进制文件等添加忽略行。始终确保只包含源文件:-)

我个人坚持使用Mercurial或Git。

Answer 5

我总是喜欢分散的VCS，如Git和Mercurial，

完全无法使用。 点。

这里的诀窍是，在您的存储库很重要的时候，您不能拥有一个分布式存储库，这种重要性（数据量）可能与大多数人无关。

如果你进行游戏开发，你将拥有大量受版本控制的资产，程序员对ZERO感兴趣。甚至大多数图形用户也不会关心。 DCS可以在您希望存储库大于典型硬盘的那一刻分崩离析。 根据你的图形有多好，你可以很容易地击中千+ gb opf存储库。 必须将其合并到我的本地存储库中作为一个程序员而不是处理除了小测试图形之外的grpahics的概念让我感到害怕 - 因为它会让网络管理员疯狂。

当你正确处理动画/电影时，这会变得更糟。 每个更改和渲染都是另一个版本。 繁荣。 这很糟糕，可以在中央存储库中处理（我可以将光盘添加到中央服务器），当你将它分发给每个版本的每个团队成员时，它就完全无法使用。

颠覆似乎是一个很好的解决方案，

可能，如果你能处理它的愚蠢行为。

我强烈推荐一个prooven解决方案 - perforce几乎能够处理它prooven。