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

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?

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...

• Note - this is intended to replace Question gamedev.stackexchange.com/questions/245/…. In 72 hours I am going to delete that question - I leave it up for now, to give people time to copy over their Answers/comments to this Question. :) Jul 15 '10 at 17:37
• This will probably end up being one of my favorite questions, if people follow the editing instructions. Working on a Game Dev specific solution for this now :D Jul 15 '10 at 17:39
• @Noctrine, you had to add the disclaimer if, didn't you? :) Of course people will follow instructions... Jul 15 '10 at 17:41
• Don't delete the other question. If it's really off topic (I don't think it is) it can be closed and archived. It can also be closed as a duplicate of this one. Jul 15 '10 at 17:42
• @Firas, it was closed - and re-opened :) Regardless, I think this formulation is better (and yes, it's a wiki) - and if people copy over their answers, this one should cover all the information in the other question. Jul 15 '10 at 17:44

# 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

• I love the idea of hierarchy of branches allowing QA to test changes before they make it to mainline, or easy creation and validation of demos. Jul 15 '10 at 18:58
• @tenpn, is that a feature of distributed VCS in general, or just Git? Jul 15 '10 at 19:08
• I've heard that Git and Mercurial both suffer when shoving very large files into them. Any truth to that rumor from people with more experience than me? Jul 17 '10 at 0:57
• Git is good and all but when it comes to handling big graphic or music assets, such as larger than 100's of MB, it becomes noticably slow at commits and check-outs. At the moment Mercurial, the contender to Git, has a "big files" extension that addresses this specific issue. If you have a game project that doesn't have a lot of assets you could give Git a try. Jul 17 '10 at 20:49
• Why not use Git's submodules to manage the binary files? That way you could create separate repositories as needed and then tie them together using submodules. Any future changes in the main repository should not affect the submodules. Jul 26 '10 at 20:43

## 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

• Interesting note about the Bigfiles Extension - that addresses one of the problems reported in the original thread, that Distributed VCS wouldn't fit well with game productions that had large numbers of binary file assets. Jul 16 '10 at 13:30
• +1 for Mercurial. It's fast, easy to use, and surprisingly powerful. :) I am using it for everything: web development, game development, private one-person projects and team projects. Thanks for introducing the BigFiles extension! Aug 6 '10 at 12:13
• With regards to large projects - TortoiseHg appears to go much slower on a large repository with 8 years of revisions than it does on a small repository with less than 20 revisions. I don't yet know whether this is something specific to Tortoise or to Mercurial more generally. Aug 6 '10 at 14:17
• There doesn't seem to be an option comparable to svn:needs-lock, and since there's also no way to tell who's locally working on what files, you're back to passing a bowl around the team, literally (you aren't allowed to edit without the bowl on your desk). BigFiles extension or not, this VCS is useless for binary files without a practical solution to this. Aug 7 '10 at 11:43
• Regardless of bigfile support, if two people edit, say, a Maya file at once, one will check in and the other will have to redo the work. With Perforce, at least, you can know that someone else is editing the file (and also automatically have a lock on that file). Sep 10 '10 at 22:06

# 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.
• Another advantage of Perforce is that it's free for the first two users, which is great for small hobby projects, or two evaluate its suitability for a larger project.
– Yacine Salmi
Jul 16 '10 at 20:01
• From my experience point 5 from your answer is very true. It is extremely scalable. Errors are rare, support is speedy. Not certain on the cost, Yacine notes that it is free for the first two users. For smaller studios with smaller games it would be worth evaluating other options. Visual Studio integration is a little off out the box; but we are lucky enough to have a complete Perforce enthusiast at our studio write an excellent source provider for VS from scratch. Jul 20 '10 at 21:16
• Perforce is awesome, if you can afford it. I've not used all of the version control systems out there, but in 10 years of commercial game development, and several version control systems, it's the best I've used by quite some margin. It handles large data files quickly and reliably, and if set up properly, performs well in a multi-site setup over relatively slow internet connections. The Visual Studio integration may not be perfect, but it's pretty solid. Aug 6 '10 at 21:44
• If I had to choose one VCS for (large scale) game development, it would be Perforce. If I could choose multiple, I would add a DVCS for text assets (code, scripts, and other miscellaneous data files) but keep Perforce for binary assets. Sep 10 '10 at 22:14
• I worked on a large game project that used Perforce and was completely bewildered that anyone would pay for it. The need to be in sync with the server is obnoxious, even on a LAN. I understand the "reconcile offline work" feature but in practice the workflow is so intrusive that when there are network hiccups you just don't work. If you don't use an IDE that has a P4 plugin, or you just want to edit a file here and there from the command line or another tool, you have to go back to the P4 client and do some bookkeeping. No other VCS puts up so many barriers to doing work. Dec 22 '11 at 1:30

## 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.

• Large projects - KDE, GNOME. Jul 15 '10 at 18:10
• * FSFS can be very brittle for recovery - so extra care should be taken with backups. * Easy to understand, TortoiseSvn is a great client. * Open source bug trackers, continuous integration systems, etc often have support for Subversion "out the box". * There's some good books available about using Subversion. Jul 20 '10 at 21:21
• @paulecoyote, this is a wiki post, feel free to edit it with new information, not just comments. Jul 20 '10 at 23:17
• SVN is great to use with Tortoise SVN (tortoisesvn.net), a client which integrates nicely into the context menu and provides guis for all actions. Unfotunably, tortoise has no Linux/Mac OS ports (at least of writing this). Protip: if working with multiple people, always update (and merge/resolve conflicts) BEFORE commit-ing. Mar 23 '13 at 19:09

## 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...

• YES! Finally one who get it: assets and code needs different tools! +1 Aug 27 '10 at 19:20
• My experience with AlienBrain is that the authors do not get game development. It is not a robust source control solution. Some of the features are nice for some of the team, but some of the coolest advertised features aren't implemented in such a way as to be useful (e.g. the staging interface, where someone can check in their assets "for review." Unfortunately there's no way to know what is for review and what isn't, and when you sync you get it anyway). Plus it caches nothing, so a sync requires testing every single file. This is slow with many gigs of assets. :) Sep 10 '10 at 22:12
• The only useful thing about AlienBrain is the preview window that works with Max files. Everything else is utter rubbish. Sep 27 '10 at 9:14
• Not sure how constructive this is since it's not first-hand experience, but I have worked on a couple projects that had been using AlienBrain before I worked on the project, and weren't using it anymore, and nobody had nice things to say about it. My memory of reading about it and catching word of mouth is that it burst on the scene, sounded really cool and some people who could afford it tried it and eventually realized it was a mistake. Dec 22 '11 at 11:43

## 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.

• The new Visual Studio Online is free for up to 5 users and hosted in the cloud (nicely backed up, etc.) Can do TFS or Git with it. Great for indie game development. Nov 19 '13 at 2:31