Switching to Mercurial

[Paul Moore]

A while back, I asked a lot of questions on this list in the process
of trying to get to grips with Bazaar. I was doing a number of
experiments looking at setting up a Subversion mirror, speed, and how
to set up a workflow for developing patches for submission to an
upstream project (usually using Subversion).

Things then went quiet for a while, as I did the same type of thing
for Mercurial.

I thought I ought to now post my conclusions to the list, as I
wouldn't have been able to do the evaluation properly without all the
help the list gave me.

In summary, I have decided to go with Mercurial. It was a close
decision, so I think it may be of use for me to explain what
influenced me.

The key reasons for this are as follows:

1. Speed. I'm sorry, but this is the number 1 problem I have with
Bazaar - it's slow. Mercurial, by contrast, is blazingly fast, and I'm
afraid it does affect how I work. It is possible to speed up Bazaar
(such things as shared repositories help a lot) but if the way I work
is dictated by the speed of my DVCS tool, then I'm afraid the battle
is already lost in my view.

2. Bazaar feels more like an "integrated solution", where there's a
set of standard ways of working, and you pick the one that suits you,
whereas Mercurial feels more like a kit of tools for you to put
together how you like. Mercurial's approach appeals to the tinkerer in
me. Clearly, this one is very subjective.

3. The confusing array of concepts puts me off with Bazaar -
checkouts, standalone branches, shared repositories, etc etc. Eek. I
really can't get my head round all the options. In contrast, with
Mercurial there is a repository, and that's it. Conceptually, there's
a lot less to get to grips with, and it's easier to get an overall
understanding.

4. Somehow, hacking on the code feels more accessible with Mercurial.
(This is a plus for me, but may not be for others :-)) It wasn't long
after I started working with Mercurial that I found a need for
something that wasn't standard - and shortly after, I'd hacked up an
extension to cover it (with assistance from the mailing list). And I'm
now diving into the sources to help resolve bugs. I never really got
involved like this with Bazaar. I don't know why - it's not that I had
nothing that I couldn't hack on in the same way, just that I didn't
feel drawn into doing so. Sorry, this is a very vague comment - it's
just that *something* in the 2 experiences made me react differently.

Some things which are roughly equal:

1. Both communities are very helpful and friendly. As I tried to get
things sorted in my own mind, I was pestering both lists with dumb
questions, and I always got positive responses. I'd say the Bazaar
list tended to be more encouraging over getting me to describe my
problems, and working to get them resolved, whereas the Mercurial list
tended to encourage and help me to fix them for myself. But both lists
made me feel welcome and gave me real help.

2. Technically, both Bazaar and Mercurial have good, but not
spectacular, means of maintaining a local mirror of a Subversion
project. The bzr-svn extension is excellent, but plagued (on Windows)
with memory issues. The Mercurial convert extension has some case
sensitivity bugs, but once these are worked around, it's extremely
fast (only 1 hour to convert the whole Python subversion trunk). Both
provide for incremental updates. Mercurial offers partial mirroring
(starting at a specified revision) whereas bzr-svn depends on Bazaar
getting shallow branches for this.

3. The documentation is about the same for both. My first impression
was that the Mercurial book was better, but having worked with both,
I'd say they are about equivalent (with the proviso that they both
reflect their projects' "mindset" - see (2) in the first section
above).

4. Extensions - Mercurial has mq, Bazaar has loom. Etc. Neither one
clearly shines here.

Places where Bazaar is better:

1. Integrated merge algorithms, and the whole merge/resolve process,
is better. Mercurial's reliance on an external merge tool, and the
need to complete a whole merge in one go, is a pain (although it's
mostly a theoretical pain at the moment, as I haven't had any complex
merges to do yet). Mercurial is moving towards a model that looks more
like Bazaar's, I gather.

2. The regular release schedule. There's a very real sense of progress
and improvement with Bazaar. Even with Mercurial's recent release of a
1.0 version, it still feels like there's less measurable progress.

3. The test suite. Mercurial's tests are based on Unix shell scripts,
and as such simply don't work on Windows (there's a hack to get them
to work, but I've never got it to run...)

Things that are irrelevant to me:

1. GUI support. I may be a Windows user, but I don't care for GUI
integration for my version control.

2. (To an extent) Bugs. Both have bugs, neither is perfect (and both
have Windows issues, in particular). Bugs are fixable, and both
projects have developers who are happy to address bugs, or for you to
offer patches yourself. So I'm not looking for perfection here - given
that neither project has showstopper bugs.

Overall, the decision was very subjective. The only concrete complaint
I have with Bazaar is over speed, and I'd concede that for smaller
projects, "fast enough" applies. But for bigger repositories (Python!)
the speed issue matters to me. Ultimately, the 2 projects seem to me
to be moving in very similar directions. On the one hand, this seems
to me to indicate that neither will ever be a bad choice, but on the
other hand, I wonder if the result is a "split vote", where neither
gains as much critical mass as they would without the other.

Anyway, once again thanks to all on the list for their help. I intend
to remain on the list and to keep an eye on Bazaar's progress. But for
now, I'm going to go for Mercurial.

I hope this is of some use to people.

Paul.

PS One thing that could do with some work is Bazaar <--> Mercurial
conversion tools! If and when I decide to switch, it's going to be
hard with the current state of things :-) (Going purely on
documentation - I haven't tried converting in practice).