Version control for game development - issues and solutions? [closed]

Question

There are a lot of version control systems available, including open-source ones such as Subversion, Git, and Mercurial, plus commercial ones such as Perforce.

How well do they support the process of game-development? What are the issues using VCS, with regard to non-text files (binary files), large projects, et cetera? What are solutions to these problems, if any?

For organization of answers, let's try on a per-package basis. Update each package/answer with your results.

Also, please list some brief details in your answer, about whether your VCS is free or commercial, distributed versus centralized, etc.

Update: Found a nice article comparing two of the VCS below - apparently, Git is MacGyver and Mercurial is Bond. Well, I'm glad that's settled... And the author has a nice quote at the end:

It’s OK to proselytize to those who have not switched to a distributed VCS yet, but trying to convert a Git user to Mercurial (or vice-versa) is a waste of everyone’s time and energy.

Especially since Git and Mercurial's real enemy is Subversion. Dang, it's a code-eat-code world out there in FOSS-land...

Answer 1

Git

Recently I have been on the Git bandwagon (I've used SVN and Mercurial). So far I really like what I get with Git. It is far from a pain to setup and more development tools are starting to adopt using it.

It's a distributed version control system. This allows for us to have our own independent trunk-like area. I can work in my own area and invite you over to view changesets very easily. I can rollback in my own space without mucking up the central repo. I can commit, branch, and do everything you can do with SVN locally. I really like having this control.

With SVN, you need access to your repo in order to commit. What if you're on the road or at a cafe with no internet? Not good.

Sure, SVN is much simpler to learn but I think the advantages of distributed source control largely outweigh the fact that it has a little learning curve.

I also like that it is smarter about merging.

A major downside of GIT is that it stores the entire history locally. (Yes, you can perform surgery to cut that down, but it's the default behavior). It's not a problem at all for source files, but if you have a large project with gigabytes of asset data, it becomes a problem quickly. In my current experience, I'd recommend GIT only for smaller or source-only repos.

If you're still curious about GIT, check out http://thkoch2001.github.io/whygitisbetter/ for some good information/metrics. Also check see https://git.wiki.kernel.org/index.php/GitSvnComparsion

Answer 2

Mercurial

Key features:

• Distributed VCS
• Free, open source
• Plugin scripts are easy to write---can be written in Python or as shell scripts
• There are many plugin scripts already freely available
• Lots of documentation available, including this book (highly recommended)

With regard to the use of non-text files, last versions of Mercurial (>=2.0) provide the largefile extension by default:

largefiles solves this problem by adding a centralized client-server layer on top of Mercurial: largefiles live in a central store out on the network somewhere, and you only fetch the ones that you need when you need them.

There are other extensions providing similar solutions like the bigfiles extension which lets you store your assets in the same Mercurial repo, but only fetch the binaries you need when you need them.

I am not aware of any issues with regard to large projects beyond those related to having large binary files. The Python project is a large project and uses Mercurial.

Joel Spolsky has written a mini-tutorial on using Mercurial at Subversion Re-education

Answer 3

Perforce

Perforce (commercial/closed-source, centralized) is the industry standard for a number of reasons.

1. It's a commercial product, which means it comes with commercial support. Open-source projects may be eligible for a free license (minus the technical support).
2. It supports workspaces very well, which allows very flexible source and asset directory layouts.
3. It supports changelists very well.
4. You can see who is working on what. Games have an abnormally high number of rapidly changing binary files (assets) compared to other development projects. Most of the time these are non-mergeable, so keeping track of who has what/where/when is critical. Subversion and DSCC clients intentionally avoid this technique, but it's quite beneficial in certain applications.
5. It supports gigantic code/asset bases. It does not store duplicate data on client machines, which is important when your sub-view of the tree is a couple dozen gigs.

That said, it's painfully obvious on an almost daily basis that Perforce doesn't feel their position in the industry is threatened. Their visual tools, including P4V and P4SCC (integrate with Visual Studio) are slow and buggy, with the latter known to freeze Visual Studio for the sheer enjoyment of it. AnkhSVN is miles ahead of Perforce.

Comment by xan: It is worth noting however that their merge tool, P4Merge (used for diffing and merging) is excellent and far superior to the likes of Tortoise Merge. Surprisingly, this component is available for free as part of the P4 Visual Tools package.

Comment by slicedlime: Another drawback with Perforce is that branching in it tends to be a huge pain, especially if you have large trees. Almost every other vcs is better at branching and merging. This is usually a small price to pay for the above advantages though.

Comment by roe: Perforce is extremely chatty. There's not much going on without the server involved. Most notably, you need the server in order to do open-for-edit, which means you need to jump through a few hoops if you intend to break the connection to the server.

Comment by jrista: As a daily user of Perforce for over two years now, with an extended development and quality engineering team of well over 100 people, I have become intimately familiar with it. While it is a decent source control system, it does have its drawbacks that those evaluating SCC systems should be aware of:

• As mentioned by others, branching/integrating is particularly cumbersome and difficult to do. You have an ungodly amount of control, but it comes at the cost of excessive complexity. On the flip side, the visual merge tool is one of a kind, and presents a beautiful three-file "based" merge view of your work. Perforce does provide some graphical visualizations of branch paths (called the Revision Graph), however the way it is visualized often makes the tool rather useless. If you only need to see a very small segment of time for one or very few files, it can be useful...anything more, and it is near impossible to navigate the Revision Graph.
• Perforce is also not a very efficient tool, as almost any file operation requires duplicating files and data: branching, labeling, change lists, etc. No sparse or lightweight tagging or branching here. If you are not afraid to use a tremendous amount of disk space tracking your changes, perforce will probably serve you well. If not, I would look to another tool.
• Perforce makes use of workspaces, however these can be frustrating at times, as perforce caches all state in your workspace, rather than using the actual files on disk to determine some state. This often results in files not getting synced because your workspace says they are up to date, when, for whatever reason, the physical files on disk are indeed NOT up to date.
• A final annoyance, Perforce is rather brutal on your network. It is an extremely chatty program, and consumes a considerable amount of bandwidth. Any network connectivity loss, and you run the high risk of being unable to do any work with your source-controlled files until connectivity is restored. As of yet, I have not discovered an activity that can be performed off-line in Perforce.

Answer 4

Subversion

• Open-source, centralized

• Blender files - I'm not entirely sure if .blend files are binary (they look like it), but I have had no problems adding them to Subversion. Having done a few experiments, the file size increase for changed files appears nominal, so it's not simply copying in the entire file.

• Large projects - It works, though it can get quirky. It's definitely able to handle repositories of at least 5.5 GB (total size of repository dir on server; mostly binary assets).

• Duplicated Data on the Client - Subversion keeps a duplicate copy of every file in the user's workspace as a pristine copy. The advantage of this is you can do a diff or revert without going back to the server. The disadvantage is that your 10 gig of working files takes 20 gig of disk space.

• The ignore list is a property of a directory (simple with a gui, annoying on the command line).

• Subversion allows locking of files/assets - which is really helpful if multiple artists and designers work on the same files.

• Externals are a great way to handle shared (e.g. library or base) code between projects.

Answer 5

AlienBrain

From Avid:

Alienbrain is a digital asset management system for artists in the entertainment industry

• Commercial (more expensive than Perforce), centralized
• Designed to integrate with other professional 2D and 3D workflow tools such Photoshop, Maya, 3ds Max, Microsoft Visual Studio, etc.

I have no experience with AlienBrain, and only heard about it from the book Game Coding Complete by Mike McShaffry. He appears to think highly of it, however:

Artists and other contributors will actually use this product, unlike others that are mainly designed to integrate well with Visual Studio and not creative applications such as Photoshop and 3D Studio Max. One of the big drawbacks of other products is their rather naive treatment of nontext files. AlienBrain was written with these files in mind.

Of course he also describes it as:

For those of you with really serious asset tracking problems and equally serious budgets...

Answer 6

Team Foundation Server

from Microsoft

• Commercial
• Centralized
• Integrates very well with Visual Studio
• Good Windows Explorer integration for non VS users (ie artists)
• Supports "Shelved" changesets, which is somewhat analogous to 'stashing' in git, but it goes up to the server; you can also make these shelvesets public, to allow other users to integrate them for you.
• Since 2012 it has a some very good code-review workflows built directly into Visual Studio
• Latest version of the merge tool is very nice. Auto merge works pretty well.
• Supports large and bindary files just fine (obviously you can't merge them)
• Very good build server
• Supports gated check-ins, which allow the quality of a shelveset to be evaluated (through automated builds, unit tests, code analysis) before it is committed to the repository.
• Very good project management tools (not strictly source-control features, but really useful), giving traceability from high-level requirements down to code.

I've used TFS extensively on MILSPEC simulator projects, and it is pretty good. Probably not the greatest if you're on a Mac, although there is an eclipse plugin these days. The cloud-hosted version supports git repositories for the source-control back-end.

It's free for up to five users on Visual Studio Online (allows closed source; no repository size limits), where it's hosted in the cloud. If you want to host it locally, it can be pricey.

The things I like most about it are the software engineering management features, and the fact that it handles large files and binary files quite happily.