Fatal error
One scary post on mercurial distributed revision control system (aka SCM system) error, by Norman Walsh, sets me to consider the different possibilities.

I read about NormalNorman Walsh problems with mercurial and I found a couple of things scary:

I read about some projects that are moving to mercurial. I think mostly OpenSolaris and OpenJDK, and I think some people at Sun made the wrong decision there. Not so much because mercurial is bad, though this is what one could carelessly infer from the error I pointed above, but because the space of distributed SCMs tools is going to be fairly competitive, and I guess git will steal most brand positioning for big software projects, leaving only space for another competitor, which I guess will be bazaar, for medium/small projects. If you forget his obvious bias for git, which he started to write, watching Linus Torvalds speak about GIT should give you an idea why distributed SCM is A Good Thing (TM).

Why is Sun choosing the wrong tool here? I think it is because they did it by the book. According to Mark Reinhold, the OpenSolaris people:

...wrote up a list of requirements, conducted a thorough evaluation of the best alternatives, and eventually settled upon... Mercurial.

In my view, comitteechecklist selection of any tool is bound to disaster, because it completely misses the feelings, that are actually esential in something that will be used a lot. It is checklisting features what leads software products to turn into bloatware, as buyers check: "three-way-merge? Yes, branch-and-remember? No,..."

Going to the gut feelings, to me git feels old school engineering, much like a Citroen, while bazaar feels literate and trendy, almost like a Mac. CVS used to be old school, while Subversion has evolved to be half way between both, say like Acrobat PDF reader. I'm not sure how mercurial feels, or darcs, the other missing piece in my book. Clues are welcome on both, and also on any other software that I have forgotten to mention.

My experience

I was using git for a while, and I found it good on the technical side, but a bit too arcane for complex operations. It still feels safe to use something that can handle both speed and size-wise a project the size of the linux kernel trees, and also www.freedesktop.org, which includes X and a fair number of drivers, libraries, utilities, etc. In fact it was tracking X stuff how I have used it mostly.

Planet venus led me to test bazaar, which is a bit less powerful than git but simpler to use, and good enough for most developments. I needed little time to patch bzr-feed.py and get the releases to point to a Trac project manager. Trac is very cool, and a well known forge for the quality of its visualizer for code changes. Ideal for small projects/companies, as it combines in a simple, easy to administer tool a wiki, a bugtracker, project timeline and roadmap, and integration with revision control systems (Subversion and CVS by default, I needed to install the bazaar support separatey). I need to ask Brian McCallister about mercurial, as he seem to be using it

Meanwhile, the Client-Server area is fairly stable, as subversion is rock solid and CVS will die a slow death. There are tools to import a subversion repo into most distributed tools (git and bazaar). Curiously enough, when most Enterprise people is just starting to do Server based version control, most FLOSS people is moving away from it towards distributed alternatives.