From The Linux Foundation
Revision as of 14:57, 21 June 2006 by Licquia (Talk | contribs)

Jump to: navigation, search


Bazaar-NG (or "bzr") is the primary candidate for replacing CVS as the FSG's preferred Version Control system. (The other is Mercurial.)

Getting Started

Bazaar-NG is available in several distributions, although most of them currenly provide an older version. Access to the FSG's repositories is recommended with bzr 0.8 or higher.

Users of Fedora Core 5, Debian "etch", or Ubuntu "Dapper" can use their distribution's version of bzr. For Debian 3.1 ("sarge"), a backport is available.

For other distributions, the current version of bzr can be downloaded from the Bazaar-NG download page. It requires Python 2.4 and the "ElementTree" and "cElementTree" modules at minimum. To use the "sftp" method of talking to external repositories, the "paramiko" and "pycrypto" modules are required.


The Bazaar-NG Web site is available. In particular, the following links are useful:

Current Trial

Migration trials are being run as of this writing. They are available at the following URL:

This will become the final site for the repositories, and the current layout is approximately what they will be for the real migration. The repository is browseable, and has roughly the same functionality as cvsweb. Unofficial user branches are stored in "unofficial"; official branches from the workgroups are stored in a workgroup directory, with released and development versions in subdirectories.

To check out a copy:

bzr branch (localdir)


bzr branch (localdir)

The webserve interface in the browser has links to the repository that work.

Issues with Bazaar-NG


By far, the biggest problem with bzr is its speed, particularly at doing the initial checkout. The initial checkout of the "build_env" repositiory in the trial has been timed to take as long as 25 minutes, and others have reported even longer times. Local operations, and updates after the initial checkout, are much faster.

The bzr developers have blamed this on an initial focus on correctness and functionality, rather than speed. Optimizing bzr is the primary goal of the 0.9 series. The current goal is to release bzr 1.0 within the next few months, so it's hoped that current speed problems are temporary.

In the meantime, Jeff Bailey has suggested that we distribute tarballs of each tree to use as an initial seed. Downloading and untarring the tree, and doing a subsequent "bzr pull", should be much faster. Once the initial tree has been successfully retrieved, subsequent operations on the tree should be acceptably fast.

An automated tarball download feature has been implemented in the current trial. In the changelog mode, there is a "download" link, which will create and send a tarball to the user consisting of the .bzr directory of the repository. This can be made into a working copy by untarring the tarball, changing into the root of the resulting tree, and running "bzr revert". After this, the directory is functionally identical to a tree created with "bzr branch".

Project Reorganization

It's been pointed out that bzr does not allow the checking out of subdirectories alone; you must check out the entire branch. Thus, it may not make sense to lump as many of the sub-projects together as they are currently organized in CVS.

Commit Rights

With CVS, since it is very difficult to maintain a local branch, pretty much anyone who did serious development on the LSB was granted commit rights. With bzr, since each branch is local, that's no longer needed. Thus, many fewer developers need commit rights. The problem then becomes: how do we get changes made by individual developers back into the main tree?

One approach is to set up something like a Patch Review Committee, who have the responsibility of merging changes from other developers in. The danger is that changes from outside the Committee might get ignored.

The bzr developers use an add-on for bzr called a "patch queue manager". Under this approach, maintenance of the official main tree is automated to some degree, with patches submitted via email or some other means. This is the solution we are planning to use. Access to the patch queue manager happens through the project web interface, which now contains a "merge" link on all repositories.

Right now, PQM is accessible to everyone. This won't work for the final deployment, of course; the current idea is to password-protect the submission page, using the directory for user access.

User Branches

Without CVS as a method of distributing patches through the official tree, we will need some other means of making new development available. Allowing users to publish their bzr branches on an FSG site is the best way for this to happen. The question, of course, is how to best do this.

The current trial has a "unofficial" section for user branches. Currently, someone with root access has to intervene to allow a user branch; this needs to be done differently.

In addition, we should have a page somewhere on the site that points to unofficial trees we find interesting, but perhaps not interesting enough to grant them space on our server.


As of 0.8.x, bzr does not have a native tagging facility. This page explains the proposals for adding tags to bzr. In the short term, Martin Pool has recommended to us that we use the tags plugin, which gives us approximately what Mercurial tags give us.

Other Problems

If you notice other issues, please add them to the wiki, or discuss them on the Discussion page if you prefer.