bzr vs svn, bzr vs hg (was Re: [Fwd: Re: Using win32_symlinks outside bazaar])

Ian Clatworthy ian.clatworthy at
Mon Oct 29 02:43:51 GMT 2007

Alexander Belchenko wrote:
> I don't know what to answer to this guy on his question:
> "I was not aware of Bazaar and its use by the Ubuntu team and have only
> become aware of mercurial through the MoinMoin people using it; we have
> been using subversion.
> I am curious, is there a paper somewhere which explains why one might
> wish to use Bazaar rather than either Mercurial or subversion?"
> Someone help me with this: "Is there a paper somewhere which  explains
> why one might wish to use Bazaar rather than either Mercurial or
> subversion?"


Those are actually two very different comparisons. Without being
negative about the other tools, I think we need to clearly explain why
Bazaar is a better choice than each of the major options - svn, hg and
git - on some Wiki pages say. I'm no expert here as I don't use the
other tools a lot. I'm happy to put together some ideas and points for
discussion. I'd appreciate input from others in our community as to
*their* top reasons for moving to Bazaar, particularly from those who
used Hg and/or Git first.

Some opening, high-level comments are given below. Please let me know if
you disagree!

bzr vs svn:

I'd tried to explain my take on why to select DVCS over central VCS
In a nutshell, it comes down to which technology better enables
collaboration (and I think we know the answer to that). One of the
Subversion team recently posted an interesting blog article on DVCS
here: Here's part of my response
(comment #56):

"Suggesting that central VCS is inherently better because it forces
developers to check in to a central location more frequently is a myth.
It’s a bit like saying “You’re allowed to talk to anyone in the company
on the phone but only through a centrally registered conference call.”
Used correctly, DVCS increases collaboration and leads to a much higher
quality trunk than I’ve ever experienced or seen by teams using central
VCS tools."

Even more interesting to me was this earlier post by the awesome Karl
Fogel titled "Subversion, DVCS and the future": Here's a gem from it:

"The reason Subversion is taking over the world
is because it is tremendously user-focused, and because it provides
well-documented APIs that enable other developers to write software on
top of Subversion. We should copy what we need from the decentralized
systems, but remember that most users don't know or care whether a
system is centralized or decentralized -- their ideal system is one
they don't notice."

So the Subversion guys are looking to incorporate DVCS ideas in 2.0
while still keeping their UI as clean and simple as possible. I think
that's a ringing endorsement of Bazaar's approach: they basically want
to get to where we are now. :-) The main reason for sticking with
Subversion right now is that the maturity of 3rd party support for it is
well beyond ours, and all DVCS tools for that matter.

bzr vs hg:

Having decided to go with a DVCS tool, the choice between Bazaar and Hg
is a lot less clear cut for many teams. My perception is that Hg has
been faster out of the box and better documented - things that really
stand out when first investigating tools. It will be interesting to see
independent benchmarks in coming weeks/months on our new pack
technology. I suspect we'll start beating Hg is some use cases while
still being a bit slower in others. I also think our doc has improved a
lot recently and will be as good, if not better, before long.

So if both tools support DVCS, are really fast, well documented and
cross platform, what's left to base a decision on? Heaps of things as it
turns out. Here's a sample:

1. Just Works. I think we have a better UI. Looking back at what the
   Subversion guys are rightly saying, defaults matter and directly
   supporting various workflow models as cleanly as we do makes a
   real difference IMO. Sure, you can simulate central development
   in Hg and Git. But it's not the same as how directly and sweetly
   we do it with bound branches and commands that feel exactly the
   same for cvs and svn refugees.

2. Ease of integration. Both have good plug-in architectures though
   ours is more flexible from what I know. Our clean API is a real
   strength as well.

In the old days, I believe our merging was better. I don't know if it
still is. Does Hg still rely on external tools for doing the merge?
Because our merging is built-in, we can pick the best common ancestor
using all the information available to us. I'm not sure how well or
otherwise Hg does this compared to us now?

Better renaming support is well publicised as well. The key point about
this is that it's not better renaming for the sake of better renaming
that matters. After all, svn and Hg are miles ahead of cvs is terms of
rename handling. The real benefit of perfect renaming support as Bazaar
has is the follow-on benefits, particularly merging afterwards. The goal
needs to be "rename if it's the right thing to do - don't avoid it just
because your tool will screw things up afterwards". That in turn drives
the right collaboration behaviour.

There are probably plenty more. The devil is in the detail and we pay a
heap of attention to detail. We think shared repositories are a better
answer to storage efficiency than hard-links + copy-on-write.  My
perception is that we place a higher value on "safety" with our
assumptions about concurrent disk access, etc. - as Robert has pointed
out previously. Our integration with Launchpad can be a huge win. I'm
not sure if Hg supports as many protocols as we do?

There are undoubtedly spots where Hg has more polish than us as well.
Ease of setting up hooks was recently raised. (We have reasons for
believing smarter hooks are more important than easy hooks but that's
not the point.) Binary file storage efficiency, unicode handling and
others have been slightly better in Hg I believe in the past. Perhaps
they still are?

Have I missed key things? If so, please speak up! We need, as
objectively as possible, to highlight why Bazaar is better and actively
address spots we've missed. I really *like* Hg. From my perspective, I
think it got a lot more right than Git. However, I really *love* Bazaar.
It doesn't tell me how to do my job but Just Works when I need it. We
have much to do but our core approach is as good as it gets today IMO.

One of the really exciting things about Robert's amazing pack stuff is
that it will start to change the debate. If the differences between bzr
and git/hg performance aren't an issue, then we can move the debate on
to where it ought to be: how do the tools enable people to work together
more effectively? That's the debate that matters IMNSHO and it's
pleasing to see the Subversion guys in particular want to be part of it.

Ian C.

More information about the bazaar mailing list