comparison with mercurial?

[Kevin Smith]

Neal Becker wrote:
> I wonder if there is anything written comparing bzr with mercurial?  They
> seem quite similar.

I don't know of any existing direct comparisons. There are several lists 
of SCM tools that include capsule summaries of both apps.

Both are in python, both have plugins, both have straightforward 
command-line interfaces, and both have strong and friendly communities. 
I'm glad to see that bzr has "shelf", to match mercurial's "mq", which 
are both similar to "quilt". I'm also happy to see that the bzr 
community is starting to develop more tools like friendly web browsing 
and desktop GUI app browsing, as the mercurial community has also been 
doing.

Generally, mercurial has been a bit more featureful, stable, and 
well-documented at any given point in time, but bzr is (hopefully) 
nearing a point of stability where it will not be a risky choice. 
Mercurial has focused on speed since day one, so is (apparently) much 
faster for large projects. Bzr may close the gap, but might not ever 
match mercurial for huge projects like the kernel. [I'm a small-project 
guy, so I'll leave the speed comparisons to other folks.]

Mercurial tagging is powerful, but unusual. I'm not sure what kind of 
tagging bzr will end up with. Bzr is shifting to the "weave" storage 
format, which is a leading-edge system that many SCM experts believe 
will open the door to superior merging algorithms and capabilities.

Bzr has more formal backing (from Canonical), but the mercurial team is 
surprisingly large and strong for such a young project, so even if Matt 
left, the project would survive. Bzr seems slightly more committed to 
the MS Windows community, although mercurial does run on native MS 
Windows too.

My own distributed SCM journey has been: darcs -> monotone -> ArX -> 
mercurial -> bzr. For me, bzr wins over mercurial because the bzr team 
is committed to:

1. Cheap http-only repo publishing (allowing all developers to be equal 
participants regardless of financial status)

2. Centralized storage (allowing cheap branches on older Win98 machines, 
and any other non-hardlink filesystem)

Those happen to be VERY important to me, since I'm most interested in 
small projects that are global and cross-platform.

Kevin