= 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.

 * OpenSolaris choice rationale: http://www.opensolaris.org/os/community/tools/scm/history/
 * Mozilla's decision explained: http://weblogs.mozillazine.org/preed/2007/04/version_control_system_shootou_1.html

== More adaptive - direct support for more workflows ==

 There's more than one way to collaborate together as explained in http://bazaar-vcs.org/Workflows. The
 best way depends on a whole range of factors. At any point in time, your team or community will have one
 primary workflow model - and the one encouraged by Hg is a very good one - but different groups within your
 community will undoubtedly mix and match as circumstances dictate. Bazaar cleanly and directly supports a
 larger range of workflows than Hg does thanks to features such as bound branches.

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 ==

 In contrast, Mercurial infers the existence of directories, has less sophisticated conflict tracking and depends
 more heavily on external merge tools.

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 ==

 Bazaar can efficiently share revisions between branches through shared repositories. It must be stated that
 these are completely optional - a standalone tree has its own repository by default. If however a parent
 directory has been configured as a shared repository, the revisions are stored - and shared - there.

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 ==

 Hg has good renaming support but it can break under certain merge conditions. If you want your team or
 community to collaborate without fear of breaking merges, Bazaar's robust renaming is essential as
 explained by Mark Shuttleworth's article on this topic.

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 ==

  * Bazaar's uncommit command is more powerful than Hg's rollback command, e.g. not just the last version is supported (which can be pretty important for a shared branch)

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 ==

 Internally, Bazaar is cleanly layered to support multiple file formats while Hg is optimized to squeeze every bit
 of performance it can out of hard-coded formats. This means that Bazaar can cleanly support both:
 
  * better formats over time, e.g. Bazaar's recently introduced pack format has technical advantages over Hg's revlog format
  * alternative formats, e.g. bzr-svn can both read and write to Subversion repositories.

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 ==

 Bazaar has a good architecture internally and a rich public API available for integrating other tools. Hg has
 plugin support as well but Hg plugins are more limited in scope.

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 ==

 Version control repositories become an important source of history over time. To maximize the data mining
 potential of this "code data warehouse", linking changes to external data sources like bug trackers is very
 important. Bazaar has out of the box integration with Bugzilla, Trac and Launchpad's bug tracker. Integrating
 other bug trackers is easy to do via either configuration settings and/or plug-ins.

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 [[https://bugs.launchpad.net/launchpad/+bug/292557|LP #292557]] and [[https://bugs.launchpad.net/launchpad-bazaar/+bug/260405|LP #260405]]).

= Bazaar's Perceived Advantages =

 * Many interesting workflows that you could just as well use with Mercurial
 * Not that slow now that they've gone through about 20 repository formats