Bugzilla:Bzr: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Created page with 'The Bugzilla Project uses the [http://bazaar.canonical.com/ Bazaar] Version-Control System. It is called "bzr" for short. You can see the contents of the Bugzilla bzr repository …')
 
No edit summary
Line 21: Line 21:
== Getting A Specific Release ==
== 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.
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 3.5.1, you would do:
 
<pre>bzr co -r tag:bugzilla-3.5.1 bzr://bzr.mozilla.org/bugzilla/trunk bz-3.5.1</pre>
 
That would check out Bugzilla 3.5.1 into a directory called "bz-3.5.1".
 
To see a list of all the tags available on a particular branch, just switch to the directory that you checked out into and do '''<code>bzr tags</code>'''.


== Checking Out Over HTTP ==
== Checking Out Over HTTP ==

Revision as of 06:59, 16 February 2010

The Bugzilla Project uses the Bazaar Version-Control System. It is called "bzr" for short. You can see the contents of the Bugzilla bzr repository at http://bzr.mozilla.org/bugzilla/.

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 3.6 branch, you'd do:

bzr co bzr://bzr.mozilla.org/bugzilla/3.6 bugzilla36

That will check out the "3.6" branch into a directory called "bugzilla36".

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 3.5.1, you would do:

bzr co -r tag:bugzilla-3.5.1 bzr://bzr.mozilla.org/bugzilla/trunk bz-3.5.1

That would check out Bugzilla 3.5.1 into a directory called "bz-3.5.1".

To see a list of all the tags available on a particular branch, just switch to the directory that you checked out into and do bzr tags.

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 bzr://bzr.mozilla.org/bugzilla/trunk bugzilla

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 status will show all the files you've modified, added, renamed, or removed.
  • If you have bzrtools installed, bzr cdiff shows a colorized "diff" of your changes, which is pretty handy and easier to read than plain-old "bzr diff".

Checking In Using Bzr

See Bugzilla:Committing_Patches.

Writing Patches On Top of Other Patches

Since we require ugzilla:Simple_Patches 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.