I was recently introduced to Mercurial version control. (http://www.selenic.com/mercurial/)
I haven’t had enough time to play with it to tell how well it holds up in all situations, but first impressions are very positive.

Things I like (a lot):
– the repository is contained within the working directory, but only in the root, so you don’t have version control artifacts spread throughout the directory structure.
– The way it handles development branches is very clever. Modifications are stored as changesets, which are then applied to a common parent. If two developers move down separate paths, it effectively creates two branches. It’s possible to change between “branches” by reverting to the common parent and then applying the changesets for the other branch.
– It’s possible to merge the two branches (called heads) together to return to a single main branch (There is a clever pattern that Dan North showed me using this that lets you merge a complex change back into another version control system)

As an example, here is how you would create a new repository once you have decided that you are going to bring it under version control (before you start, right?) 🙂

We start in the working directory of the project:
– hg init (tell Mercurial to create a repository)
– hg addremove (add all files in this directory and subdirectories to the repository)
– hg ci -m “Created repository for Project X” (commit the changes to the repository)

The ease with which you can create a new repository along with the fact that it is stored alongside the working copy without all the versioning artifacts mean that Mercurial is going to be my version control system of choice for my personal projects going forward (sorry subversion)