I'm starting a new blog "feature", "RPG Anvil", for discussion of topics related to the creation of a computer RPG, such as programming, design, writing, etc. Perhaps at some point I'll formally introduce what "RPG Anvil" is meant to accomplish, but for now I'm just going to dive right in.

Today's topic is Mercurial, specifically using Mercurial as source control for a one-man project, on Windows. "What is Mercurial?", you ask. Mercurial is one of the hot new "distributed" source control systems, favored by open-source projects.

But, I see some blank stares; as background let's start with source control. Source control is a system that stores and moderates access to source code; note that source code is a pretty broad term and can include art, documents, or whatever else you want. A good source control system will provide complete history (of all changes or revisions) for all of your code, will allow you to easily retrieve your source code from any particular time, and will provide services for multiple developers to modify the source code at the same time, usually with some sort of merge functionality. Traditional source control systems consist of a "server", which stores the master copy of the source code, and every developer on the project runs a "client", and enlists in some or all of the source code.

For any development project with multiple developers, a source control system is pretty much a must. It's even in the "Joel on Software" Test: http://www.joelonsoftware.com/articles/fog0000000043.html. However, working on large projects at Microsoft, I've grown to appreciate source control, and it's desirable even for a one-man project. Before now, my backup and history strategy has been to make a zip file of the source code every time I complete a milestone (every month or two). This is pretty effective, if crude, on the large scale, but with no granular change tracking, some things are just a pain. For instance, if a feature broke, but I didn't notice for a couple of weeks, there's no way I can go back and find which change broke the feature and why, and instead I'll have to spend more time figuring out the code again. OK, for those of you who haven't used source control, that may not sound like a big deal, but it is.

So, I've decided to run source control on my personal projects. The goals are:

1. Provide granular history for all source code.


2. Help prevent accidental loss of code.


3. Provide some way to "tag" the code for a particular release so I can retrieve it (like the zip file).


4. Perhaps most importantly, the source control system should not impose significant effort or resources to use. I'm just one guy, so if even a few scant percent of my time is spent futzing with source control, it's not worth it.

I'm used to the traditional source control systems; Microsoft uses something called "Source Depot", which people claim is a modified version of Perforce. It works pretty nicely, although as with all long-lived software systems some parts of it a pretty byzantine by now. Of course it scales madly; lots of people work on the Windows code!

So, I set out to find something like that. The current king of open-source source control systems is called Subversion; a guide for setting it up on Windows can be found here: http://www.codinghorror.com/blog/archives/001093.html It seems to be about what I expected; traditional, client/server as I'm used to. However, while reading the comments, I saw a lot of reference to the new distributed source control systems. Linux uses something called "Git", and other popular options include "Mercurial" and "Bazaar". Since one of the points of my private projects is to learn new things, I decided I would try one of these, if feasible. I probably already have a good idea of how things will work in Subversion, but how about "Git"?

After some brief "research" (does reading blog comments and scanning a couple of web pages really count as research?) I decided Mercurial was my best bet. Git is poorly supported on Windows, and more people seemed to recommend Mercurial than Bazaar. So, perhaps somewhat arbitrarily, that was my starting point. I'll get into some more details of how I'm using Mercurial in a following post. For now, the main Mercurial website is http://www.selenic.com/mercurial/wiki/index.cgi, with various links giving information how to install on Windows.

Now, I haven't been using Mercurial for a long time yet, so I can't comment on its reliability or stability. But otherwise, I can definitely recommend it for a one-man source control system. Some things that I like:

1. Has all the source control basics in a set of simple, reasonably well documented commands.


2. There is no need to run a server! The source code (and associated repository) sits in a directory on my file system, and when I need to perform a source control action, I run a command-line tool. Since I'm not sharing my code with anyone, there is no need to have any persistent code running.


3. By using good practices, it's actually quite easy to make sure that all code is under source-control, which can be a bugaboo for one-man operations.


4. The "master copy" of the source code is just my source code, same as before. Mercurial stores all of its revision information off in a separate directory.

The "no server" operation is really cool for my purposes. Typical source control systems will need to have a "server" (which might just be a service on the same machine), with it's own copy of the source code and revision information. But with Mercurial, this is completely unnecessary. In fact, even for multi-developer projects, you can operate without a server, though it makes sharing more of a manual process (you have distribute your Mercurial revisions via email or something of the sort). Mercurial supports this system well... at least in theory. Without any other developers on my project, I haven't had occasion to try it out.

My complaints thus far would be:

1. In a manner typical of open-source projects, you sometimes have to dig around in different web-sites and different places to find all of the information you need, particularly for the Windows version. In fact there appear to be different installs of Windows Mercurial, though the first one I tried worked fine.


2. There are various (sometimes contradictory) suggestions for organizing your repository. I think I've found something that works for me, but best practices, especially for interaction with Visual Studio, are not clear at first glance.


3. I'm very much comfortable with command-line source control. There are solutions for Explorer or Visual Studio, but they are separate downloads, and I didn't try them at all.

If you're a one-man project, running on Windows, I'd definitely recommend using Mercurial to store all of your source code. After just a couple of hours of ramp-up, you'll be developing like normal, with very little overhead, but all the benefits of source control. I'll make another post later about some practices for setting up, using, and managing your Mercurial installation.