Bzr For Users Of Other VCSes
If you've used another Version Control System, there are guides for how to use Bzr based on your knowledge of that other system.
Checking Code Out of Bzr
The simplest way to get the latest Bugzilla development code is:
bzr co bzr://bzr.mozilla.org/bugzilla/trunk bugzilla
That will check out the "trunk" branch into a directory called "bugzilla". (If you leave out the "bugzilla" on the end, you'll get a directory called "trunk" instead.)
If you want other branches, replace "trunk" with the name of the branch. For example, to get the 4.0 branch, you'd do:
bzr co bzr://bzr.mozilla.org/bugzilla/4.0 bugzilla40
That will check out the "4.0" branch into a directory called "bugzilla40".
Getting A Specific Release
Every time we release a version of Bugzilla, we "tag" the bzr repository so that the point in history that matches with that release can be explicitly checked out of the repository. For example, to check out Bugzilla 4.1.3, you would do:
bzr co -r tag:bugzilla-4.1.3 bzr://bzr.mozilla.org/bugzilla/trunk bz-4.1.3
That would check out Bugzilla 4.1.3 into a directory called "bz-4.1.3".
Note that you have to specify the right branch, also, for the release you want. So, for 4.0.2, you would do:
bzr co -r tag:bugzilla-4.0.2 bzr://bzr.mozilla.org/bugzilla/4.0 bugzilla-4.0.2
Note that that command reads
bugzilla/4.0 instead of
To see a list of all the tags available on a particular branch, just check out the branch without any tag, switch to the directory that you checked out into, and do
Checking Out Over HTTP
If for some reason you can't access port 4155 (which is what the bzr:// URLs are using) on bzr.mozilla.org (maybe you have a firewall at your company that prevents accessing unknown ports), you can check out the Bugzilla code using HTTP by just replacing "bzr://" in the above links with "http://", like this:
bzr co http://bzr.mozilla.org/bugzilla/trunk bugzilla
Updating to a Newer Release
There are two types of updates: updating from one minor release to another (like 4.0 to 4.0.2) and updating from one major release to another (like from 3.4.x to 3.6.x).
If you are just updating from one minor release to another (like from 4.0 to 4.0.2), all you have to do is change to your bugzilla directory and do:
bzr up -r tag:bugzilla-(version)
Where (version) is the version number that you want to update to, like
4.0.2. So, for example, to update from 4.0 to 4.0.2, you would do:
bzr up -r tag:bugzilla-4.0.2
After running update, if bzr tells you there are any conflicts, you should edit those files and fix the conflicts.
If you are updating from one major release to another (like from 3.4.x to 3.6.x), then the simplest method for upgrading is to run the following commands:
bzr switch (major version) bzr up -r tag:bugzilla-(full version)
Where (major version) is the first two numbers in the version (so, if you were updating to 3.6.6, the "major version" would be
3.6) and (full version) is the whole version number you want to update to (
3.6.6, if you were updating to 3.6.6). So, for example, to update from 3.4.10 to 3.6.6, you would do:
bzr switch 3.6 bzr up -r tag:bugzilla-3.6.6
However, if you have committed customizations to your bugzilla directory using bzr commit --local, or used "bzr branch" to check out instead of "bzr checkout", "bzr switch" does not work and should not be used. Instead, you should follow the instructions at Bugzilla:Bzr:Porting_Forward_Customizations.
Creating Patches With Bzr
See Bugzilla:Patches for information on how to produce patches in the format that the Bugzilla Project prefers.
If you just want to see what changes you've made to your checkout, there are a few useful commands that can help:
bzr statuswill show all the files you've modified, added, renamed, or removed.
- If you have bzrtools installed,
bzr cdiffshows a colorized "diff" of your changes, which is pretty handy and easier to read than plain-old "bzr diff".
Checking In Using Bzr
Writing Patches On Top of Other Patches
Since we require simple patches, you may often find yourself needing to write a patch "on top" of another patch that you just wrote and that hasn't been reviewed yet. One option is to wait until each small patch is reviewed, and only then write the next one. But that can get pretty slow. So instead of slowing down your development, a better option is to use bzr-loom, a plugin for bzr that allows you to have separate patches on top of an existing code base, and even keep them up-to-date easily as the upstream code base changes.