Delta Engine Blog

All about multiplatform and game development

Trying out Git and why distributed versioning is not really for game developers.

After watching the following video from Linus Torvalds about Git and testing several versioning tools this week again (see my previous post about all kinds of source versioning tools like TFS, VSS and SourceGear Vault), I decided to give Git a chance. A friend of mine is using Mercurial for his personal projects by utilizing VisualHg (Mercurial plugin for VS). Mercurial is very similar to Git (from my limited knowledge), both are distributed revision control systems, which means no central server and everyone has a peer-to-peer like repository. This this involves much more merges, branches and applying patches to many different repository versions, merging is much more important than in a centralized versioning tool.

The only reason I even watched the following presentation about Git (it does not really tell you much) is because Linus was bashing CVS, Subversion and many other versioning tools so hard. Some true points, but some people really disliked his style. I found it entertaining.

You can find more documentation and a second video with more technical details about Git on the Git Documentation website.

Well, all this Linux crap can be interesting from time to time, but as long as there is no Visual Studio integration, I'm not really ever going to use it anytime soon. However, there is a pretty successful GitExtensions project, which includes a very good integration to Windows, the Explorer and even Visual Studio 2005/2008. After installing this and trying it out for a while I kinda liked how nicely everything integrates into this tool-set. You got Putty or OpenSSH, KDiff3, all the command line support for playing around and you can even integrate all kinds of other merge tools from Subversion, Perforce or whatever you like better. Using GitExtensions is definitively easy and I can see why it would make sense in a highly distributed open source project, everyone can work on his own version and changes or fixes are around at different places. It can also be used for small teams, then everyone trusts each other and can merge all the changes whenever they want. Merging changes is pretty cool tool, there is no need to do it twice, once a programmer has merged something, it is merged for everyone else once he pulls the new version.

However, I will not be using Git for neither my personal projects nor at work. First of all I do mainly game development and while source files are important, there are many other file formats to consider and Git does not store them in any useful way. Because of the distributed model it is impossible to lock a file, which means any changes to any binary file can result in loss of work (or worse: more work since someone has to merge changes yourself by hand). I have read many discussions about this yesterday and some people are just retarded to not see the point. If you just put text files into Git, everything is fine, but once you have binary files that might change (why else would you even put them into a versioning tool), you can get into trouble. I'm not saying tools like Subversion are better, but at least they allow you to lock files, to announce to everyone in the team: "This file is mine now, please wait until I'm done changing it". With more than 3 people and with lots of un-merge-able binary files this is currently the only way this can work efficiently. Sure we could use two or three different kind of versioning tools (one for programmers, one for content, and even specialized ones for artists, which integrate into their tools, etc.), but what is the fun in that?

But that is not really the reason not to use Git for source code. Merging works pretty good for text files and since you can do a lot more merges and be much more efficient, it sounds really useful. Git even tracks if you remove code from one file and put it into another file, you can still see history of it, etc. The reason I really dislike Git and many many other versioning tools is simply: It is freaking annoying to use all the time. You may only waste 10-30 seconds for pulling, committing local changes, pushing them to somewhere else, selecting files that have changed, adding comments, doing a quick merge, etc. every time, but if you do that many times a day, a lot of time is used just for that. You don't believe me? Just watch the 5 video tutorials on the GitExtensions homepage, or check out the Git Documentation, its samples and video tutorials. It is not hard to use these tools, but it costs a lot of time constantly doing all this crap. I fully understand that this might be very necessary for huge projects like the Linux Kernel or useful and wanted for distributed open source projects, but that is not what I want to do all day and that is not what I want my employees doing.

I like if the source control system is completely hidden and ALL actions are done automatically by just working on the project!
- You open Visual Studio to start working? All files are updated automatically!
- You edit a file? The file is checked out to you automatically, others can still work on it, if it is a merge-able file, but they know that you are already sitting on it (maybe both of you are trying to do the same thing, check work tasks again). But even if both people are required to change a file, there is usually never a problem if you check-in often!
- You are done working? Just close Visual Studio and everything gets checked in automatically with a nice comment (required). Or just commit in the middle of the day as much as you want if you think your changes are important or needed right now.

Easy as that. We pretty much worked that way in the last project, except we used Subversion and we had HUGE amount of files (20+ GB just binary content). On some slower PCs it took 10+ Minutes just to get the latest files. Then we had to manually Update everything every morning just to start working. Committing happened when done working or when something important was finished. But many commits just fail in a big team because you have to update again since someone else changed something. Then there is the worst part: Merging. Sometime it works fine. "Luckily" we only had a few developers working on the same files so most changes could be merged, but from time to time there were really bad merging conflicts. Empty lines could not be merged, comments were slightly different (e.g. we had to disable automatic comment and header generation just because of constant conflicts of really unimportant stuff) and if you were really unlucky some changes were merged into a uncompilable mess. Even worse, sometimes you could compile it, but some game logic was now buggy or some config files were messed up. What I also hated about Subversion was the fact that I could never get a complete version of the repository at home, there was always some stupid checksum error, network corruption, https not working, etc. problem that prevented some 200MB file not being downloadable.

Again, it all depends on what you are working on. For example our artists had not much problems with Subversion except for the long update times, annoying cleanup and rare mess-ups that happened from time to time. But then again they never versioned their work data, they just checked in the final files to be used in the game. That alone eat up many 100 GB on the repository. I bet the Linux kernel team is happy with Git and many years ago when I was using VSS for myself I was also happy with it (not much can go wrong if you are by yourself ^^). For our next project I also don't want to have the whole repository of everything on my small SSD, e.g. subversion needs everything twice, git would even need more than that since every version is in the .git directory plus the actual working files, fine for text files, not fine for huge binary files. Only give me the stuff I really need for working, not sure how to do this for content yet, but I bet there is some crazy setting in Perforce to do it or we just write some tools ourselves that only get stuff that is required for execution (unit tests, editor, etc.).

Still had not really time to dig into any of the new tools I wrote about in the last weeks, but for now I will stay with SourceGear Vault and its painless integration to VS. It looks like our Artists disliked AlienBrain (mostly because of the fact that it does not even support the recent 3DS Max 2010 version for over 6 months now), for that reason they are currently evaluating Perforce, which is kinda hard to get used to at first, but it is fast for binary files and it integrates nicely into everything (Photoshop, 3DS Max, Maya, etc.) and we can also use it for our project management (OnTime) and hopefully integrate all that together with our build tool (whatever it might be, I'm currently liking Cruise Control). I don't think I like Perforce for us coders since the VS addin is very old school and might cause some pain. The server setup was also not easy at all, there are no admin tools on the server, you have try to use the stupid P4V program or even better the command line to fix up stuff. Currently we got a delay of 5s for all operations and we have no idea where it is coming from. Probably have to set it up again and try all kinds of settings to get it into a usable state. That is something I really liked about SourceGear Vault, installation took 2 minutes and everything was working out of the box. It might be a more simplistic tool, but that's what I'm looking for :)

Useful links: