Bazaar

Bazaar

 




Wiki Tools

  • Find Page
  • Recent Changes
  • Page History
  • Attachments

Differences between revisions 13 and 14
Revision 13 as of 2007-12-16 00:02:26
Size: 14117
Editor: AaronBentley
Comment:
Revision 14 as of 2007-12-16 00:48:20
Size: 15371
Editor: AaronBentley
Comment:
Deletions are marked like this. Additions are marked like this.
Line 41: Line 41:
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.
Line 43: Line 45:
 * Directories are tracked, not just inferred, so it understands if and when a directory is renamed  * 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.
Line 143: Line 145:
= Response to Mercurial =

Some points in response to [http://www.selenic.com/mercurial/wiki/index.cgi/BzrVsHg Mercurial's response] to this page.

 * Mercurial's use of hard links between repositories does not make them 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.

Bazaar vs Mercurial

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 [http://www.selenic.com/mercurial/wiki/index.cgi/BzrVsHg Mercurial response].

TableOfContents(2)

Overview

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 is undoubtedly a very good tool. In particular, its developers have done a good job of ensuring it is scalable to really large projects. Bazaar's design goals were different but it has recently made huge strides in performance while maintaining its many strengths. Bazaar has been designed to be suitable to a wide range of people, workflows and environments. Bazaar may well be the right choice for your community or team.

This document compares Bazaar 0.92 with Mercurial 0.9.5. Note that both tools are continuing to evolve so some of the points below may not apply in the future. In fact, Bazaar is rapidly evolving each and every month at a rate faster than Hg. That said, here are some common reasons for selecting Bazaar over Hg today:

  • More adaptive - direct support for more workflows
  • Better merging - fully integrated
  • Better storage model - shared repositories
  • Robust renaming - collaborate without fear
  • It Just Works - UI is less complex
  • Cleaner architecture - better layering
  • More flexible plugins - not just new commands
  • 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 previous advantages.

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.

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 actually far 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 a big deal.

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.

Robust renaming

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 collaborate and refactor without fear of breaking merges, Bazaar's robust renaming is arguably essential. See [http://www.markshuttleworth.com/archives/126 Mark Shuttleworth's article] for further discussion on this topic.

It Just Works - UI is less complex

While Hg has a better UI than Git, Bazaar's is cleaner still. Here are some examples:

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

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.

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.

More flexible plugins - not just new commands

A VCS tool is only part of the broader Collaborative Development Environment required by communities and teams. It needs to be integrated with a 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.

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.

Launchpad integration

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.

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 [http://www.amazon.com/dp/0321336380?tag=integratecom-20&camp=14573&creative=327641&linkCode=as1&creativeASIN=0321336380&adid=0PGFZH8377CYXSDPY06E& 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.

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.

Mercurial's Earlier Advantages

Mercurial had some notable advantages over earlier versions of Bazaar including:

  • Speed
  • Storage efficiency
  • Documentation

With the introduction of [http://doc.bazaar-vcs.org/latest/developers/knitpack.html packs] into 0.92, Bazaar is now much better than earlier versions in the areas of speed and storage efficiency. In some cases, our benchmarking of packs is showing better results than Mercurial; in other cases, the differences in speed are much less than before. If Bazaar (with packs) is notably slower than Mercurial for a particular use case of yours, please let us know. We know of additional areas where we can make further large performance improvements so there ought to be more good news on this front in coming months.

Documentation is another area where Bazaar is making good progress. A new [http://doc.bazaar-vcs.org/bzr.1.0/en/user-guide/index.html User Guide] has shipped with Bazaar 1.0. Improvements have been made to the [http://doc.bazaar-vcs.org/latest/en/mini-tutorial/index.html 5-minute tutorial], [http://doc.bazaar-vcs.org/latest/en/user-reference/bzr_man.html User Reference] and [http://doc.bazaar-vcs.org/latest/en/developer-guide/HACKING.html Developer Guide] in recent months. A one page [http://doc.bazaar-vcs.org/latest/en/quick-reference/quick-start-summary.svg Quick Start Card] has been added. These [:Talks: slides] may help people that need to train others as well.

Response to Mercurial

Some points in response to [http://www.selenic.com/mercurial/wiki/index.cgi/BzrVsHg Mercurial's response] to this page.

  • Mercurial's use of hard links between repositories does not make them 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.

Related Links

The following links may also be of interest: