subversion... ..or git?

I was listening to Andy Schatz talk at GDC today about how he created the IGF-winning game Monaco in 15 weeks. The IGF-winning build, anyway - the game still hasn't been released just yet. Perhaps the most interesting thing about these talks is not the actual stated content itself - one can find roughly 80% of the best bits for free by searching on "GDC" on Google. Twitter is awesome right now because of all the news stories that are bubbling up with various sites reporting on the event this week. I was actually able to review a good portion of the day's talks by just reading other people's accounts of them in articles linked to from Twitter. (you can find a writeup of Schatz's talk today here: http://bit.ly/eSi76g)


Where the real value of GDC is coming for me is not from the free Android devices, although I am kicking myself a little now for not attending the Google dev days, but rather in between the lines of the talks. It's what the speakers aren't saying, but is plainly obvious to me as I look at their slides or their mannerisms on/off stage. Andy Schatz did not once mention anything technical about subversion, other than a brief mention that he did in fact use subversion. What got my attention was that he was using it from day 1 of Monaco - and that he hardly mentions it, which would imply that he's been using it so long that it's just stupidly obvious

And it should be. Keeping a handle on the changes going on in a codebase is too much boring to make one's brain go through. Solution? Get a program to do it!

This, surprisingly enough, never really occurred to me before. Source code versioning is one of those things that, if I have the tool to do it around and I know how to use it, then I will be a good little user of that tool and version all my code and everything is good. If do not have such a tool in my possession, or just do not know how to use it, I'm back to hacking out code and manually making backup copies every once in a while, when the mood strikes me. And such is the case here - I don't like to think about source code versioning techniques. Just give me the damn tool. And I hadn't even heard of CVS/SVN until I was well into college, and didn't get into serious code versioning practice until I was working at Microsoft.

When I was at Microsoft, we used an in-house tool/system called Source Depot, which, I'm told, is based off an older version of Perforce. The two codebases are said to have diverged quite a ways back and so are a bit different now. Now that I do not work for Microsoft, I do not have any Source Depot anymore, for better or worse. No Perforce, either ($$$).

As far as the free options go, Subversion is the way to go for a client/server model, which is what Perforce and Source Depot (and many others use). There's also Git, which is what the Android project as well as the Linux Kernel project use for their code versioning, which relies on a distributed model.

After some fiddling around through documentation/tutorials on both SVN and Git, I settled on Git because I can run it without a server on my laptop, get vetted version control system going for my project, and it's quite lightweight. I was able to integrate it with Unity by enabling source control from the editor, which essentially just exposes the previously-hidden asset metadata as files that can be checked in, and then doing the initial create/import/commit like one would with any other project directory.

To paraphrase another Andy Schatz takeaway that I thought was really insightful: make something cool every day that you can genuinely be excited about. Keep a steady pace of goodness flowing into your build tree. Try not to do things that take more than a day to do start to finish. Whatever you do, just make something cool every day.

While I would hardly place source code control systems at the top of my list of cool things, the benefit of having source code control on my project now is awesome. Maybe tomorrow I'll try something equally not-always-obviously-cool - maybe an automated test of some sort... ;)