We where talking about merging today and one of my co-workers pointed out that some of the advantages of Distributed Revision Control Systems (DRCS), are actually more of a case of "distributed rcs rules because I never read the manual for svn and drcs is complex enough that it forced me to read the manual". For example Joel Spolsky (of Joel on Software) writes about Mercurial:
The interesting part is that these systems think in terms of changes, not in terms of versions.
That's a very zen-like thing to say, I know. Traditional version control thinks: OK, I have version 1. And now I have version 2. And now I have version 3.
And distributed version control thinks, I had nothing. And then I got these changes. And then I got these other changes.
Uhmm, no, that's not quite right. On the back-end Subversion stores changesets not versions, and since way back in the 1.0 days the documentation has always encouraged a model of thinking about changes not versions, see the section on merging in the old Subversion book for instance. The difference is that when he didn't understand Subversion it was forgiving enough that he could still use it, but with Mecurial he had to go and read the manual. Not that there aren't real benefits to using Mecurial or Git, but they often "solve" problems with Subversion that are just as well solved by reading the Subversion manual.
By the way Technically most revision control systems store changesets rather than versions, and then generate the "version" you need when you request it, at least back to RCS from '82. Though some would encourage you to have a mental model of versions instead of changesets.
PS. I use Git myself for most of my personal projects, and the company I work for (Codesion) plans to add support for Git some time this year, and also switch our internal development over to Git at some point, so it's not like I have some sort of hatred of DRCS.
