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

时间:2011-11-27 13:12:52

标签: git svn version-control mercurial

我们是一个团队,正在考虑使用Unreal Development Kit制作游戏,我们正在寻找版本控制解决方案。

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

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

5 个答案:

答案 0 :(得分:8)

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

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

水银

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

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

在2.0之前,主要使用了两个扩展名:

  1. Bfiles extension,用作2.0
  2. 中新扩展程序的基础
  3. Bigfile extension,在我看来,这比其他两个要复杂一点
  4. GIT中

    我不太熟悉Git处理大文件的可能性,但我知道存在各种解决方案。这篇文章应该给出一些好的指示:Managing large binary files with git

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

    SVN

    我已经将SVN与大文件一起使用,并且我没有比开箱即用的Mercurial(没有扩展名)更好地管理它们的印象。

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

    结论

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

    每个版本的二进制文件都存储在一个单独的集中式目录(Mercurial术语中的largefile store)中,当一个dev克隆存储库或更新到特定的变更集时,只有从这家商店下载所需文件

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

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

    总而言之,我真的不明白为什么Git或Mercurial不能胜任这项任务,没有其他答案给出任何真正的理由。

    在我看来,大型游戏公司坚持使用较旧的工具,因为更改需要时间,而当您为某些东西付款时,您会使用它!有多少公司仍在使用VSS或CVS,因为层次结构不会听到任何其他内容?我们上个月刚刚迁移到TFS(来自VSS),我正在工作......

答案 1 :(得分:1)

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

答案 2 :(得分:1)

Hq(Mercurial) 2.0支持大文件很棒。

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

答案 3 :(得分:0)

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

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

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

就个人而言,我会坚持使用Mercurial或Git。

答案 4 :(得分:0)

  

我一直偏爱分散的VCS,如Git和Mercurial,

完全无法使用。点。

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

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

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

  

Subversion似乎是一个很好的解决方案,

可能,如果你可以处理它的愚蠢。

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