Difference between revisions of "Bazaar"
|Line 111:||Line 111:|
=== Speed ===
=== Speed ===
By far, the biggest problem with bzr is its speed, particularly at doing the initial checkout.
By far, the biggest problem with bzr is its speed, particularly at doing the initial checkout. initial checkout of the "build_env" repositiory 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 bzr developers have blamed this on an initial focus on correctness and functionality, rather than speed. Optimizing bzr is primary goal of 0. to .'.
An automated tarball download feature has been implemented
An automated tarball download feature has been implemented the . 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 ===
=== Project Reorganization ===
Revision as of 18:54, 31 January 2007
- 1 Bazaar
- 1.1 Getting Started
- 1.2 Documentation
- 1.3 Repositories
- 1.4 Issues with Bazaar-NG
Bazaar (or "bzr") is in the process of replacing CVS as the LF's preferred Version Control system. Bazaar was previously known as Bazaar-NG (to distinguish it from the older Bazaar project (or "baz"); most of the pages on this wiki still call it Bazaar-NG. Mercurial (or "hg") was also seriously considered.
Bazaar-NG is available in several distributions, although most of them currenly provide an older version. Access to the LF's repositories requires bzr 0.8 or higher.
A package for bzr exists that aims at LSB compliance, depending only on lsb-python in the Application Battery. It includes bzr itself, its dependencies, and a few useful plugins. A package for bazaar 0.14 is available here:
- lsb-bzr for ia32, x86_64
- Older versions available if needed:
- lsb-python for ia32, x86_64
Please request additional architectures on the mailing list.
Installing Base Software
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. The bzr project also maintains a list of available bzr ports at their distro downloads page. There may be more up-to-date information on availability. Remember that the LF repositories require bzr 0.8 or higher.
If a packaged version won't work or doesn't exist, 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.
If you do need to build an alternative version of Python to support these packages (some distributions can't upgrade the system version from 2.3), make sure to use that version when installing them. For example, if you built Python 2.4 and installed it as
/usr/local/bin/python24 make sure you install the modules by running
python24 setup.py install.
Plugins are add-on code modules which extend bzr, enhancing current features and adding new ones.
Distributions which package bzr itself often package plugins as well; search for a "bzrtools" package to see. For unpackaged plugins, the bzr site has good installation instructions.
One plugin in particular used at the LF is "tags". You must have this plugin installed to access tagging information in our repositories, or to add new tags. See the Bazaar-NG Tags page for more details.
Another plugin that looks useful for projects (such as LSB) which have multiple repositories is the "update-mirrors" plugin. With this plugin, a single command "bzr update-mirrors" in a directory that holds branches of multiple repositories can do the effect of a "bzr pull" on each.
(modified from []):
One function of a version control system is to keep track of who changed what. In a decentralized system, that requires an identifier for each author that is globally unique. Most people already have one of these: an email address. Bzr will auto-generate an email address by looking up your username and hostname, but this is only right if you always run bzr from the same machine and don't use a different email address as your identifier (such as @linux-foundation.org). We need a user's commits to have the same identifier over time! Here are some options:
- Set the email address in the ~/.bazaar/bazaar.conf by adding the following lines. Please note that [DEFAULT] is case sensitive:
[DEFAULT] email = Your Name <email@example.com>
Override the previous setting on a branch by branch basis by creating a branch section in ~/.bazaar/branches.conf by adding the following lines:
[/the/directory/to/the/branch] email = Your Name <firstname.lastname@example.org>
- Override the two previous options by setting the global environment variable $BZREMAIL or $EMAIL ($BZREMAIL will take precedence) to your full email address.
CVS wizards may (or may not) benefit from Bazaar-NG For CVS Users.
The Bazaar-NG Web site has lots of useful info, although not specific to LF usage. In particular, the following links are useful:
All LF repositories are available at the following URL:
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 http://bzr.linux-foundation.org/unofficial/(project) (localdir)
bzr branch http://bzr.linux-foundation.org/lsb/3.1/(project) (localdir)
The webserve interface in the browser has links to the repository that work.
At the moment, only the OpenPrinting, LSB development, and unofficial repositories are live; the rest are still being managed in CVS. These bzr repositories are synchronized with CVS nightly. They can be branched, modified, and merged through the Bazaar-NG Patch Queue Manager, but any merges will be overwritten nightly when CVS changes are pulled in.
So, for those projects which are still being synchronized with CVS, the proper place to make real changes is still CVS. Merging changes with these projects is still possible, but only as a test of the merge process.
When a project switches to bzr, the CVS repository will become read-only, the following error message will appear on attempted checkins:
cvs commit: Pre-commit check failed cvs [commit aborted]: correct above errors first!
Note that at this time, migrated repositories do not sync back to cvs XXXX
Issues with Bazaar-NG
By far, the biggest problem with bzr is its speed, particularly at doing the initial checkout. During the trial (in the bzr 0.8.x timeframe), the initial checkout of the "build_env" repositiory was 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 a primary goal of bzr development leading towards 1.0. There have been noticable speed improvements in subsequent releases to where 0.14 didn't feel anywhere near as slow (but specific timing tests have not been repeated).
An automated tarball download feature has been implemented through the webserve. 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". This will likely ALWAYS be faster for initial branch creation.
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.
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?
We are planning to use an approach the bzr developers also 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. Development is done on local branches, which are then made available online, and a request for a merge is submitted via a web interface, linked to from the bzr-webserve browser interfaces (via the "merge" link).
Access to PQM requires authentication. Access to merge patches is granted on a per-workgroup basis.
For more information, see the Bazaar-NG Patch Queue Manager page.
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 LF 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. For more information on how they work, see Bazaar-NG User Branches.
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 (local branch), which gives us approximately what Mercurial tags give us. See the Bazaar-NG Tags page for more details.
If you notice other issues, please add them to the wiki, or discuss them on the Discussion page if you prefer.