I've noticed how much monotone has changed my habits and views on version control. From being a fairly mature CVS user and hacker, I've now fully moved to use monotone as much as I can. It was most noticable a couple of days ago, when I worked on some project that's still versioned using CVS, and wondered why so many files were missing, until I realised I had forgotten to update with -dP... Those flags used to be second nature!

The thing that attracted me the most about monotone was its off-line capabilities and the way it keeps track of history, which is essential to get merging working the way I want (contrary to the way I have to do it with CVS, with all the dealing with tags and all). I've also come to realise that the way it works leads to a different approach to work flow:

Maintainance branches:

many large projects that use CVS, for example OpenBSD and OpenSSL, use separate branches to maintain one or two "current" versions of the product while still being about to do "bleeding edge" development in the trunk. When you want to make a change (a bug fix), you might need to do it in a maintainance branch and then merge the results into the main trunk, which leads to the typical merge hassle with CVS. With monotone, it's a bit of a different story. First of all, you don't really have to deal with separate maintainance branches. Since a branch can have multiple heads, all you need to do it is to update to the latest release, make your change and commit, then tag it. If you want to merge the change with the other (or all the other) head(s), you simply merge. Of course, it might be more practical to have a separate branch for maintainance, but at least there is the option! There is no such option with CVS.

Looking at it as things to follow up on:

Just an hour or two ago, someone said there was a bit of an error in Makefile.am in the monotone source. I decided to take it on, and decided to do it in a slightly different way. Instead of just update to the head and make the change there, I updated to the revision where the error was introduced, made the correction, committed, which of course created a second head, and finally merged While being something of an experiment, it taught me another way to look at source development, as responses to very specific events. Basically, I treated this particular event as an email to follow up on, which creates a link between the other emailer (committer) and me, and a thread of emails (revisions) to follow. Kind of a different view, much more like people responding to each other than people dealing with a big blob called the source and whatever "magically" happens in it. A kind of social interaction between developers, maybe far away from each other.