Version control system for game development with UDK?

Question

We're a team thinking of making a game using the Unreal Development Kit and we're looking around for version control solutions.

I have always preferred decentralized VCSs like Git and Mercurial, and used it for all my personal projects. Though I have heard of problems regarding game development using these systems, with them not being suitable for big binary files.

Subversion seems like a good solution, however I have not used it at all in the past, so I don't really know what it offers.

Answer 1

You can use Mercurial or Git without a problem. I don't know why @TomTom states otherwise in such a way without providing any hints about the reasons.

Sure you will have to manage the various binary files that comes with every game development (movies, texture, maps, etc). But both software have ways to handle them.

Mercurial

Mercurial has various extensions to deal with large files, especially binary ones.

Since version 2.0, the Large File extension is included in Mercurial and you can use it without downloading anything else. Files are not directly stored in the repository, but Mercurial tracks which version of the file is needed for each changeset, so you can download a precise version of your game with the right file when you need them.

Before 2.0, there was mainly two extension used :

1. Bfiles extension , which was used as the base for the new extension in 2.0
2. Bigfile extension , which is a little more complicated than the two others in my point of view

Git

I'm not really familiar with Git possibilities to handle large files, but I know various solution exists. This post should give some good pointers : Managing large binary files with git

I've hear a lot of good about git-annex .

SVN

I've used SVN with large files, and I don't have the impression that it manages them better than Mercurial (without extensions) out of the box.

If you decide to use an extension to manage large files with Mercurial / Git, Subversion is way behind in term of functionnality.

Conclusion

About your concern to keep the binary files version in sync with the source, bot Mercurial and Git extensions handle this very well.

Each version of the binary files is stored in a separate centralized directory (the largefile store in Mercurial terms) and when a dev clone the repository or update to a particular changeset, only the needed files are download from this store.

You can even use the same store for various repository !

The process of adding a file to the store or updating it is nearly transparent to the dev, so no problem about a long learning curve for example.

To conclude, I really don't see why Git or Mercurial are not up to the task and no other answer gives any real reason.

In my opinion, big game companies sticks with older tools because change takes time and when you've paid for something, you use it ! How many companies out there are still using VSS or CVS just because the hierarchy won't hear anything about something else ? We just migrated to TFS (from VSS) last month where I'm working...

Answer 2

I'd stick with Git. What you may lose with the storage of large binary files, you'll more than gain in being able to work together as a team. You'll be updating, changing, merging your code a lot more than just storing binary files, and DVCSs handle this a lot better.

Answer 3

Hq(Mercurial) 2.0 support of big files is great.

Previously it was LargefilesExtension , but from the version 2.0 this is distributed with core.

Answer 4

Big game studios generally use http://www.perforce.com/ (to be honest, I have no idea why.)

SVN is a pretty good option as well, but it's a bit outdated compared to Git and Mercurial.

Anyway, why would you put large binary files on the repository? You'll definitely want to add ignore lines for all compiled binary files, etc. Always make sure to only include source files :-)

Personally I'd stick with Mercurial or Git.

Answer 5

I have always preferred decentralized VCSs like Git and Mercurial,

TOTALLY unusable. Point.

The trick here is that you can not have one distributed repository the moment your repository is significant and this significance (data amount) is possibly irrelevant for most people.

If you do game development, you will have tons of version controlled assets that programmers have ZERO interest in. Even most graphics people wont care. DCS break apart the moment you can expect your repository to be larger than a typical hard disc. And depending how good you are graphics wise you can easily hit thousand+gb opf repository. The concept of having to merge that into my local repository as a programmer not dealing with the grpahics except small test graphics makes me kringe - as does it drive the network admin mad.

This gets even worse when you properly deal with animations / movies on top. Every change and render is another version. Boom. This is bad enough to handle in a central repository (where I can add discs to a central server), it is totally unusable the moment you distribute that to every team member IN EVERY VERSION.

Subversion seems like a good solution,

Possibly, if you can deal with it#s stupidities.

I would strongly recommend a prooven solution here - perforce is pretty much able to deal with it prooven.