I'm a fan of monotone, a modern, decentralized version control system. In my opinion, monotone is the cleanest and most thought through VCS available, so it's probably no wonder I'm using and enjoing it. I've started hacking it, since it is still lacking some features I'd like it to have. In February 2007, I've had the pleasure to attended the first monotone summit, which took place at the Googleplex in Mountain View, CA.
The very first project I've been using monotone for is Postgres-R, because subversion was just a PITA: first of all, I've often messed up with branch propagation, because svn doesn't track that for you. Second, it's merge algorithm is — ehm.. non existant — I needed to merge trivial changes again and again. And third, if you are not connected to your subversion server, you are limited to the last revision you've checked out. No diff, no log, no data from older revisions at all. That's why I decided to give monotone a try. I've imported the complete PostgreSQL CVS repository and started a branch for my own work with Postgres-R. Propagating from the main development branch of PostgreSQL to my Postgres-R sources works much smoother with monotone and I only have to resolve real conflicts.
Unfortunately the CVS importer for monotone does not connect branches, which makes the import of the branches mostly useless. Thus I've had a look at cvs2svn and how they import from CVS. Just at that time, they proposed a new algorithm, which got implemented as cvs2svn 2.0 by now. That looked reasonable to me, so I've started adapting that algorithm for monotone. You can read more details about the algorithm in the CvsImport page of the monotone wiki. My work is available in the monotone branch net.venge.monotone.cvsimport-branch-reconstruction.