On the weekends and during off-hours from Peach I've been pecking away at a personal animation project of mine. It isn't even at the 3D stage yet—I'm still writing the story and doing character design—but still, I'm a revision control junky, and I want my files versioned. So versioned they will be.

My first reaction was to use Subversion, but I would need to set up a server for that. Making an online server for a small personal project (that might not even get off the ground) seemed like overkill, but on the other hand, making a local server on my laptop would tie my project to my laptop which seemed equally silly.

So what was a poor soul like me to do?

I decided that it was time to look for alternatives. I had heard of a few other revision control systems, namely: Git (used for the Linux kernel), Arch (the GNU solution), Mercurial, and Bazaar. So I decided to check them out.

The thing that all these systems have in common is that they are all decentralized revision control systems, meaning that they don't use a centralized server (at least not by default) to store revisions. It's sort of a peer-to-peer approach to revision control. Instead of having a central repository, each person working on a project gets their own local copy of the entire revision tree (called a "clone" or "branch"). This is handy because it means you can use revision control locally, committing to your own local copy of the repository. The primary means of combining changes then becomes merging branches rather than committing to a repository. It took me a bit to wrap my head around this, as I'm used to the commit paradigm, but it really makes a lot of sense.

In my case it's especially useful because I just want to version something locally anyway, so this paradigm fits my needs perfectly. Anyway, back to the different systems I looked at.

I quickly ruled out Arch for two main reasons. First, I couldn't find it in the ubuntu software repository and I didn't want to install it by hand just to try it out. Second, I read quite a few reports claiming that arch is fairly anti-user-friendly. Since I haven't tried it I can't verify those claims, but the combination of that and not being able to conveniently try it out was enough to put me off.

Next up was Git. Git is actually pretty user-friendly (although not entirely so). Unfortunately, it isn't (conveniently) cross-platform. It seems people have gotten it to run on Mac OS X and Windows, but there aren't any ready-made installation packages. So for most intents and purposes, Git is Linux only. And I'm not too keen on tying my data to a single OS, even if it is my OS of choice.

Then I tried Mercurial. And it was good. Really good. I mean it. Despite the title of this blog entry, Mercurial is a solid piece of software, and quite friendly to boot. In fact, I almost stopped at Mercurial because is was so good. It just worked. And it's cross-platform. But... sorry to say, I think Bazaar is just a bit better. However, I definitely recommend Mercurial as well.

Finally I tried Bazaar. And I'm glad I did. Bazaar just makes me happy. Everything is easy as pie (except for things that are inherently difficult, of course). Mercurial is almost as good, but falls short of Bazaar on two points:

1. Mercurial does not explicitly track file/directory moves. Instead, like SVN, it treats moves as a copy and a delete. This makes merging divergent directory structures and file names painful at best. If the same file is renamed to different things in two branches, and if those branches are merged, then Mercurial will just see the files as two copies from a root file, not recognizing that there is a renaming conflict. So you end up with two copies of a file with two names. Bazaar, on the other hand, explicitly tracks moves, so it will report (and in fact force you to resolve) the rename conflict. This is a far, far better behavior in my opinion. In short, Bazaar is robust at dealing with restructured directory trees and file moves/renames. Mercurial is not.

2. Mercurial isn't quite as intuitive to me. This is a bit subjective, however. To me Bazaar's branch and merging models just make more intuitive sense. Bazaar presents each branch from that branch's point of view. So if I merge from another branch and commit the merge, the entire set of revisions that were merged from the other branch are seen as being under that single commit. When you look back through the logs, you then see a sort of hierarchy that distinguishes between changes you made locally, and changes that are the result of merges. In Mercurial, on the other hand, everything is on the same level. So after you've done a merge you can't really tell what was you and what was the other person. Both approaches make sense, but I find Bazaar's to be more intuitive. It directly represents how each particular branch was constructed.

So, yeah, I'm in love with Bazaar. After playing with it for a week or so I've realized that I probably want to use it instead of SVN in all cases, not just for small personal projects. Decentralized revision control just makes more sense to me, honestly. SVN is cool, but its paradigm seems outdated to me now.

In any case, if you use revision control, I recommend giving Bazaar (and Mercurial, too) a whirl.