I have been using Monotone for several months, including keeping my home directory under VC and synchronized between my desktop, server, and laptop, and have been quite pleased with it. I like its systems of using hashes as version IDs, and having one SQLite file for the entire database seems like a good idea.
Monotone got a little slow after I added several thousand files, but then I noticed there is a flag to first check against cached inodes (http://monotone.ca/docs/Inodeprints.html#Inodeprints) instead of recalculating the hashes for everything every time. It's apparently disabled to have a default stance of extreme caution, but doesn't seem to pose anymore risk than, say, using a journaling filesystem, and speeds things up dramatically. The few evaluations I've seen of mtn wrote it off as slow, without trying this.
The "algebra of patches" system in Darcs looks interesting, as well. As I understand it: every change has its inverse calculated, so you can apply / undo any combination of patches in the entire history. I haven't used it for more than a few quick experiments, though.
- primary local branching is done in the same repository without needing to create multiple parallel directories.
- local branches need not correlate to public branches on a remote system.
- keeping local branches current with trunk/master is dead easy when using rebase.
- using interactive rebase is incredibly powerful for splitting, combining, rebuilding or reorganizing a set of commits on a local branch.
- commit amending is dead simple, for those times when you miss adding a file (or part of a file) and catch it the moment after you've hit the enter key.
- much better two-way integration with SVN. I work on projects hosted using SVN using Git, and I gain all the benefits of local branching, etc, and I can still push all my changes perfectly easily to the server whenever I want.
Basically, Git is powerful, flexible, and designed to fit a more natural style of development (IMO), and really puts the developer in control at all times. After the initial shell shock of finding that "standard" source control commands work a bit different in Git (as compared to SVN, Hg, etc), and you learn the what/why/how of the staging area (the index), I've found Git to be the most development-friendly source control tools around, and for the first time in the history of using source control, I have never once cursed the tool for doing/not doing something wrong/stupid. That alone has made me a lifelong convert.