(→Initial Setup: Update.)
(→Documentation: Update, prune old links.)
|Line 66:||Line 66:|
== Documentation ==
== Documentation ==
:Bazaar ] , .
CVS wizards may (or may not) benefit from
CVS wizards may (or may not) benefit from [http://.bazaar../].
== Repositories ==
== Repositories ==
Bazaar (or "bzr") is the Version Control system in use by several workgroups at the Linux Foundation.
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.
Bazaar is available in nearly all recent distributions. Access to the LF's repositories requires bzr 2.0 or higher.
Prebuilt binaries are available for a number of platforms via the Bazaar download page.
The current version of bzr can be downloaded from the Bazaar download page. It requires Python 2.4 and the ElementTree and cElementTree modules at minimum; the latter two modules are a part of Python 2.5 or later. To use the "sftp" method of talking to external repositories, the paramiko and pycrypto modules are required.
Bazaar's source tree is set up so it can be used easily without installing if necessary. Just run the "bzr" executable at the root of the source tree.
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 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 [here]):
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 an email address via bzr whoami. This is the simplest way.
To set a global identity, use:
% bzr whoami "Your Name <firstname.lastname@example.org>"
If you’d like to use a different address for a specific branch, enter the branch folder and use:
% bzr whoami --branch "Your Name <email@example.com>"
[DEFAULT] email = Your Name <firstname.lastname@example.org>
[/the/directory/to/the/branch] email = Your Name <email@example.com>
The Bazaar documentation site has lots of useful info, although not specific to our usage.
CVS wizards may (or may not) benefit from BzrForCVSUsers.
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.
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. Currently-supported versions of bzr, with the newer repository formats, are much faster.
An automated tarball download feature has been implemented through the webserve interface. 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".
Another useful tool is the smart server. Currently, use of the smart server requires shell access on the LF Web server; we are investigating making a read-only server available.
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.
For some of our very old branches, native tag support was not present in Bazaar. We used a tag plugin (available at its upstream or our local branch), which gave us approximately the same functionality as Mercurial tags. See the Bazaar-NG Tags page for more details.
All recent development uses Bazaar's native tags support, and all old tags were migrated in the development repositories.