Bazaar vs Mercurial
This page is obsolete!
See Ten reasons to switch to Bazaar instead.
Note: This document is not intended to be an unbiased comparison, but to present some of the reasons for selecting Bazaar over Mercurial, as seen through the eyes of Bazaar developers/users. YMMV. Mercurial is a great tool - if you like Bazaar, you'll generally like Mercurial and vice versa. There is also a similarly biased Mercurial response which readers are encouraged to consider.
- Bazaar vs Mercurial
- Reasons for Selecting Bazaar over Hg
- Mercurial's Earlier Advantages
- Features Unique to Mercurial
- Response to Mercurial
- Related Links
Distributed VCS does have compelling advantages and selecting the right tool is far from easy. Many teams have Bazaar and Mercurial (Hg) on their shortlist and are investigating both in further detail. This document aims to provide information to assist in comparing the tools.
Mercurial's development started by concentrating on scalability to large projects. Bazaar's design goals were initially different. The performance and scalability has progressed from release to release while maintaining its many strengths. Speed is now one of the key metrics changes to Bazaar are assessed on. Bazaar key focus has been its suitability to a wide range of people, workflows and environments. Considering Bazaar's adaptibility, it may better meet the needs of different teams and communities.
This document compares Bazaar 1.0 with Mercurial 0.9.5. Here are some common reasons for selecting Bazaar over Hg today:
- More adaptive - more workflows are directly supported
- Better merging - fully integrated
Better storage model - shared repositories & packs
- Robust renaming - good for collaboration and refactoring
- User Interface - often preferred
Flexible architecture - supports multiple formats & more flexible plugins
- Launchpad integration - free code hosting, branch registries and more
- Integration with related tools
- Commercial training and support.
Each of these topics in discussed below, together with some comments on Mercurial's early advantages. Please note that both tools are continuing to evolve so some of the points below may not apply in the future. Bazaar in particular is rapidly evolving each and every month, something made possible by its suite of 10,000+ tests.
Reasons for Selecting Bazaar over Hg
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.
It should be noted that Hg does support several workflows as documented here: http://www.selenic.com/mercurial/wiki/index.cgi/WorkingPractices. The strength Bazaar has is that central workflows (in particular) are more directly supported thanks to features such as bound branches.
Better merging - fully integrated
If a DVCS needs to do one thing really, really well, it's merging. Merging needs to "Just Work" and "Always Work" by leveraging all of the knowledge available. The cost of a suboptimal merge in terms of wasted developer time can be high. The cost of a merge gone wrong - appearing to work when really it didn't - is potentially far more serious.
VCSes like Bazaar and Mercurial do inventory-level merging: they rename files, change file permissions, create new files, and change files into symlinks or directories. Text merging ala diff3 is only part the merge process.
Many Bazaar users nominate its intelligent built-in merging as one of the primary things they love about Bazaar. Here are some key features:
- Directories are tracked, not just inferred, so it understands if and when a directory is renamed. Directory tracking ensures that new files appear in the correct place.
As it tracks more semantic knowledge than other tools, Bazaar can do a better job of tracking and reporting different conflict types: text, content, duplicate paths, unversioned parent, missing parent and several more (see http://doc.bazaar-vcs.org/bzr.0.92/en/user-guide/conflicts.html)
- Users can nominate different merge algorithms, e.g. knit-merge (which handles criss-cross merging better than 3-way merge), for all or selected files
- External merge tools may optionally be used.
In contrast, Mercurial infers the existence of directories, has less sophisticated conflict tracking and depends more heavily on external merge tools.
Note: Getting merge right is far harder than it sounds. For example, see http://article.gmane.org/gmane.comp.version-control.monotone.devel/3264 for an explanation of how 3-way merge can silently corrupt your code if the common ancestor is selected in a naive way. See http://revctrl.org/CategoryMergeAlgorithm as well for examples of different merge algorithms.
No server setup required
Although the fastest way to transmit changes is over to use our smart server, Bazaar can also use plain sftp and ftp servers. WebDAV support is also available using a plugin.
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.
From an efficiency perspective, this is more flexible and powerful than Hg's model. For example, the one repository can be used on a developer workstation for storing revisions from:
- release branches
- a tracking branch of the main development trunk
- topic branches for each fix or feature currently being worked on
- temporary QA or integration branches for reviewing other changes.
Some topic branches might be pushed to a location publicly accessible (like ~/public_html) which others might be experimental only. With Bazaar, it doesn't matter - they can all efficiently use the one repository without worrying about others accidentally pulling junk they don't need. For users on laptops in particular, this can be useful.
Bazaar's approach has value well beyond the single user case. In commercial environments, different teams might have their access controlled to various branches (e.g. development vs QA vs maintenance) on a server but, once again, these branches can be using a shared repository for efficient storage. It's also clearly beneficial for hosting sites like Launchpad.
For some sample figures on how shared repositories combine with our new pack format for end user benefit, see Storage Efficiency below.
Hg has good renaming support but it can break under certain merge conditions. The big thing that makes Bazaar's renaming support better is that it understands and tracks directory renames, an important feature for developers refactoring in languages like Java where package names are mapped to directories. If you want your team or community to be able to refactor without worrying about merging, Bazaar's robust renaming is arguably essential. See Mark Shuttleworth's article for further discussion on this topic.
User Interface - often preferred
Different people like different UIs. While Hg has a much better UI than Git, Bazaar's is better still, at least according to most users we hear from that have used both systems in some depth. Here are some examples of places we think our UI is better:
- Hg has commands that Bazaar doesn't need, e.g. heads, parents, unbundle
- Bazaar's send command is more powerful than Hg's bundle command, e.g. email and merge directives are supported
- 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)
- dotted revision numbers provide a more natural/structured view over the graph of revisions.
Technically, a branch is a directed acyclic graph (DAG) in Bazaar just like it is in Hg. Practically though, a particular series of revisions is most important from the perspective of the owner of each branch. Here are some examples:
- If a developer is working on a topic branch, makes some changes, does a merge and commit and asks for a log of the last 5 changes, then the merge is logically (only) one and the 4 changes before it ought to be listed as well
- If a team is running a Continuous Integration server that triggers a full build+test after each commit, then the CI server should only be triggered after each commit to the main development line, not commits to merged branches.
Treating the left-hand side of the DAG (mainline) as special doesn't make Bazaar less distributed as some people have suggested. Instead, it recognizes that each branch has its own viewpoint onto the DAG. Bazaar's UI has been designed to reflect this.
Bazaar has a good architecture internally and a rich public API available for integrating other tools. Hg has a plugin architecture that supports adding/changing commands. Bazaar's plugins can pretty much do anything you can dream of.
Internally, Bazaar is cleanly layered to support multiple file formats. This means that Bazaar can cleanly support both:
- better formats over time
- alternative formats, e.g. bzr-svn can both read and write to Subversion repositories.
In the future, it is quite conceivable that different Bazaar repositories will be adopted for different applications of version control - managing source code implies different trade-offs to managing photos, music, etc. Even within the source code configuration management space, Bazaar could evolve to become a universal front-end to different legacy back-ends.
Note: A VCS tool is only part of the broader Collaborative Development Environment required by communities and teams. It needs to be integrated with heaps of other tools and the overall solution needs to be manageable over time. A plugin architecture has many advantages including reduced Total Cost of Ownership.In this regard, we think that both Bazaar and Hg have a better approach than (for example) Git.
Launchpad is a free service provided by Canonical which is designed to make it easier for open source communities to collaborate both internally and with other open source communities. Features include free hosting of Bazaar branches, a registry of branches for projects, linkage of branches to the bugs and blueprints they address and more. A huge amount of open source software is available as Bazaar branches within Launchpad. For a detailed look at how Bazaar and Launchpad can be used together and why good integration matters, see http://people.ubuntu.com/~ianc/doc/en/tutorials/using_bazaar_with_launchpad.html.
Integration with related tools
Bazaar has been integrated with some useful related tools in ways that might help your team. These tools include Patch Queue Manager (PQM), Bundle Buggy (BB) and various bug trackers.
Continuous Integration (CI) is a best practice adopted by many open source projects and commercial teams using Agile/Lean development methodologies like XP and SCRUM. The objective is always having a shippable code base by early detection and correction of when things break. Here are the core CI practices as given by chapter 2 of Paul Duvall's book:
- commit code frequently - commit centrally at least once per day
- don't commit broken code
- fix broken builds immediately
- write automated developer tests
- all tests and inspections must pass
- run private builds
- avoid getting broken code.
A better workflow for achieving this is called Decentralized with automated gatekeeper as explained in http://bazaar-vcs.org/Workflows. PQM is a software gatekeeper which ensures that the mainline of the development branch never breaks. It is maintained by a member of the Bazaar team and well integrated with Bazaar.
Bundle Buggy (BB) is a tool for tracking peer reviews. It is maintained by a member of the Bazaar team and well integrated with Bazaar. See http://bundlebuggy.aaronbentley.com/help.
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. Hg has plugins integrating it with Bugzilla and Trac as well.
Commercial training and support
In addition to support from an active open source community, Bazaar professional services for commercial organizations are available from Canonical. If you require conversion, training, support or custom engineering for Bazaar, please contact Canonical to discuss your needs.
For commercial Hg support, see http://www.selenic.com/mercurial/wiki/index.cgi/Support.
Mercurial's Earlier Advantages
Mercurial had some notable advantages over earlier versions of Bazaar including:
- Storage efficiency
Before 1.0, Bazaar's default file format was knits, a format similar to Mercurial's revlog. It now uses a format similar to Git's format - packs - for many good reasons: it performs better, it's more efficient and it enables useful features to be delivered (like history horizons) that would be far more complex to make robust otherwise.
In most cases, Bazaar's speed is now close enough to Mercurial's on common operations for the difference not to matter. If you find otherwise for a particular use case of yours, please let us know. (We know of additional areas where we can make further performance improvements so there ought to be more good news on this front in coming months, particularly for network operations.)
Grab the latest version of your code base, import it into Bazaar (init-repo, init, add, commit) and into Mercurial (init, add, commit). Check the disk usage. Create a branch, make a fix, commit it and check the disk usage again. Here are the results (du -s) for a snapshot of the Mozilla tree comparing Bazaar 1.0 with Mercurial 0.94 (the latest version with binaries) on Ubuntu 7.10:
So Bazaar is around 10% better, at least in this case. It should be noted that both systems are extremely good though - the vast majority of the space is taken up by the working trees, not the (compressed) history. If storage efficiency is critical to you, you might like to have a single working tree and reuse it across multiple branches as explained here: http://doc.bazaar-vcs.org/bzr.1.0/en/user-guide/index.html#reusing-a-checkout.
Documentation is another area where Bazaar has made great progress during 2007. A new User Guide has shipped with Bazaar 1.0. Improvements have been made to the 5-minute tutorial, User Reference and Developer Guide in recent months. A one page Quick Start Card has been added. These slides may help people that need to train others as well.
Features Unique to Mercurial
If you know of any, please edit this page and add them.
Until recently, Bazaar was missing an equivalent to Mercurial Queues. This is now provided by Looms.
Response to Mercurial
Some points in response to Mercurial's response to this page.
- Mercurial's use of hard links between repositories makes them logically independent, but not physically independent. Since they share files through hard links, damaging one repository may also damage others.
- You are correct that tracking directories has nothing to do with textual merging, but it does improve the quality of inventory-level merging.
- The point of the workflow discussion is that while Mercurial can be used in centralized workflows, Bazaar has explicit support for them, and so works better with them.
- Bazaar does not randomly change history. Even if you uncommit a revision from your branch, it is still present in your repository, and you can use it later if you like. It takes a fair amount of effort to remove revisions from Bazaar repositories, because they are designed to be append-only.
It is true that Bazaar has been evolving file formats as we've added functionality (e.g. tags) and focused on performance during 2007. We've taken the best ideas from Mercurial (dirstate) and Git (packs) and combined them, adding support for the additional metadata (e.g. directories) we track that other systems don't. As systems add features requiring more data to be tracked, evolving file formats is the right thing to do in our opinion. If Mercurial is enhanced to supports features on our roadmap (like nested trees and history horizons), perhaps it will need to do the same thing in the future. After all, there are very good reasons why Git and (now) Bazaar use packs.
The following links may also be of interest: