← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/en/user-guide/bug_trackers.txt

  • Committer: Canonical.com Patch Queue Manager
  • Date: 2007-12-20 16:16:34 UTC
  • mfrom: (3123.5.18 hardlinks)
  • Revision ID: pqm@pqm.ubuntu.com-20071220161634-2kcjb650o21ydko4
Accelerate build_tree using similar workingtrees (abentley)

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/en/user-guide/bug_trackers.txt
1
 
Bug trackers
2
 
============
 
1
Integrating Bazaar with bug trackers
 
2
====================================
3
3
 
4
4
Bazaar has a facility that allows you to associate a commit with a bug
5
5
in the project's bug tracker. Other tools (or hooks) can then use this
6
 
information to generate hyperlinks between the commit and the bug, or to
7
 
automatically mark the bug closed in the branches that contain the commit.
 
6
information to link between the commit and the bug, or to automatically
 
7
mark the bug closed in the branches that contain the commit.
8
8
 
9
9
Associating commits and bugs
10
10
----------------------------
17
17
This records metadata in Bazaar linking the commit with bug 12345 in
18
18
Launchpad. If you use a different bug tracker, it can be given its own
19
19
tracker code (instead of ``lp``) and used instead. For details on how
20
 
to configure this for Bugzilla, Trac, Roundup and other bug/issue trackers,
21
 
refer to `Bug Tracker Settings`_ in the Bazaar User Reference.
 
20
to configure this, refer to `Bug Tracker Settings`_ in the Bazaar
 
21
User Reference.
22
22
 
23
23
.. _Bug Tracker Settings: ../user-reference/bzr_man.html#bug-tracker-settings
24
24
 
34
34
appropriate for your project's workflow.
35
35
 
36
36
Note: This second processing stage is part of the integration provided
37
 
by Launchpad when it scans external or hosted branches.
 
37
by Lauchpad when it scans external or hosted branches.
38
38
 
39
39
Making corrections
40
40
------------------
52
52
order to make it again with the correct options. This is commonly done
53
53
to correct a bad commit message and it equally applies to correcting
54
54
metadata recorded (via ``--fixes`` for example) on the last commit.
55
 
 
56
 
Note: ``uncommit`` is best done before incorrect revisions become public.