Overview

This page is a response to the document at http://bazaar-vcs.org/BzrVsHg, detailing why bzr is so much better than hg. Obviously, not everyone agrees on that; in fact, some large projects like Mozilla, Xen and the OpenSolaris and OpenJDK projects from Sun have already chosen to use Mercurial (see ProjectsUsingMercurial). Linus Torvalds, in his Google Tech Talk on revision control systems, pointed out Mercurial as the only other tool than git (the system he designed himself) worthy of consideration. Here are some things from the BzrVsHg document that are inaccurate or deserve a more neutral explanation.

More adaptive - direct support for more workflows

All of the workflows on the linked Workflows page can also be used from Mercurial. Although Mercurial doesn't currently support bound branches as explicitely distinct feature, that workflow can be archieved using the hooks support that Mercurial provides.

Better merging - fully integrated

The fact that Mercurial infers the existence of directories doesn't have anything to do with the capability of its merging algorithm. It does allow using external merge tools, which makes it easy to switch in your favorite merge tool.

Better storage model

In fact, local clones (branches) of any Mercurial repository on a capable file system use hardlinks to share their repositories. This means that, in effect, the same files are used to save most of the repository information for all the branches, similar to Bazaar's shared repositories. It is worth noting that the significant advantage of shared repositories in bzr is that it increases performance (by sacrificing repository independence). The Hg repository format generally outperforms (often significantly) both modes without making repositories interdependent.

Robust renaming

The problems mentioned here have long been fixed. If some are still there, it would have been nice if they were pointed out explicitly.

It Just Works - UI is less complex

hg has a backout command, which provides similar functionality, but does it by keeping the history intact (instead of deleting changesets, it commits new changesets that reverse the older changesets). In fact, the immutability of changeset history is an important reliability and performance feature of hg.

Cleaner architecture - better layering

Well, it seems Bazaar's internal repository format has changed a number of times by now. By contrast, the repository format for hg was changed once, after some experience using the former format exposed some inefficiencies. hg has also gained a convert format that allows it to read from other types of repositories (currently, CVS, Darcs, git, Bazaar, Monotone, GNU Arch, Perforce and Subversion are supported) and write to some of those repositories (this feature is still in development).

More flexible plugins - not just new commands

The plugin support for Mercurial is fine. One of the oft-used plugins for Mercurial (mq), in fact, uses a different Repository object in order to layer some extra functionality on top of normal repositories. In addition, Mercurial has hooks infrastructure, which allows plugins and other code to plugin to some of the actions going on in and around a repository.

Bug tracker integration

Mercurial ships with a Bugzilla plugin. Trac has a very competent TracMercurial plugin (which is regarded within the Trac community as the best DVCS plugin available). Indeed, Mercurial provides no integration with the proprietary Launchpad platform (see LP #292557 and LP #260405).

Bazaar's Perceived Advantages

BzrVsHg (last edited 2010-02-12 13:46:09 by DirkjanOchtman)