My experience was that switching from Subversion to Mercurial involved a substantial learning
curve and also a change in development processes - you have to work the way the tool expects you
to work. In fact, after a week we gave up - it may well have been worth persevering, but we ran
out of patience. The Mercurial documentation does warn you that this experience is not unusual.
Yeah, I would expect that to be the case for a team. I would note that it isn't so much that the
tool imposes changes on a development team, it's that this class of tool was created to enable a
different way of working. That's naturally going to mean changes if the tool is to be used fully
and not just as a better drop-in for the old tool (which pretty much describes SVN).
My original comment was based on the fact that Mercurial is intentionally similar to SVN in command
syntax, particularly for the most common commands. For the simplest case of a single master
repository with a single (or very few) committer, the learning curve is pretty shallow. Not flat,
mind you, but shallow. When giving it a try for personal projects based on SVN, Mercurial was easy
to transition to and much less painful than Git, though they are quite similar in general philosophy
(though Git is nice to use as well once the command syntax is grokked, and at some level
interchangable with Mercurial). The point was that for XOM, which has a fairly standard and simple
repository structure and (as far as I can tell from a quick glance at the online repo) a single
committer without a complex team to deal with, the transition would perhaps not be so painful.
I suppose there's little point to switching anyway. To be honest, DVCS is a tool of the bazaar, and
XOM has more of a cathedral-like air about it.
So never mind - stick with SVN.