← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

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

  • Committer: John Arbash Meinel
  • Date: 2005-09-29 21:13:03 UTC
  • mto: (1393.1.12)
  • mto: This revision was merged to the branch mainline in revision 1396.
  • Revision ID: john@arbash-meinel.com-20050929211303-7f1f9bf969d65dc3
All tests pass.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/ja/user-guide/bug_trackers.txt
1
 
バグトラッカー
2
 
===============
3
 
 
4
 
Bazaarにはコミットをプロジェクトのバグトラッカーのバグに関連づけできる機能があります。
5
 
コミットとバグの間のハイパーリンクを生成する、もしくはコミットを含むブランチで閉じた\
6
 
バグを自動的にマークするために、他のツール (もしくはフック) はこの情報を使うことができます。
7
 
 
8
 
コミットとバグを関連付ける
9
 
---------------------------
10
 
 
11
 
コミットを行うとき、 ``commit`` の ``--fixes`` オプションを利用することでバグと関連付けることができます。例です::
12
 
 
13
 
    $ bzr commit --fixes lp:12345 -m "Properly close the connection"
14
 
 
15
 
このコマンドの実行によってコミットとLaunchpdのバグ12345とリンクするBazaarのメタデータが記録されます。
16
 
異なるバグトラッカーを使う場合、( ``lp`` の代わりに) 独自のトラッカーコードを渡して代わりに使うことができます。
17
 
Bugzilla、Trac、Roundupとその他のバグ/問題トラッカーに対してこれを設定する方法の詳細に関しては、
18
 
Bazaarユーザーリファレンスの `バグトラッカーの設定`_ を参照してください。
19
 
 
20
 
.. _バグトラッカーの設定: ../user-reference/index.html#bug-tracker-settings
21
 
 
22
 
メタデータの記録 vs バグトラッカーの更新
23
 
------------------------------------------
24
 
 
25
 
コミット時に修正されたバグに関するメタデータの記録は完全なバグトラッカーの統合機能の中で唯一必要なものです。
26
 
Bazaarは分散型VCSなので、ユーザーがオフラインでコミットしているためバグトラッカー自身へのアクセスが不可能な場合があります。
27
 
代わりに、プロジェクトのワークフローに適切な中心位置に変更をpushするとき、\
28
 
バグトラッカーを更新するためにフックをインストールすることが推奨されます。
29
 
 
30
 
注: この2番目の処理段階はLaunchpadの外部もしくはホストされているブランチがスキャンされるときに
31
 
Launchpadによって提供される統合機能の一部です。
32
 
 
33
 
訂正をする
34
 
-----------
35
 
 
36
 
リビジョンとバグを関連付けるこの方法にはいくつかの制限があります。
37
 
最初のものは関連づけはコミット時のみにしかできないことです。
38
 
このことは、コミットするもしくは修正した後でバグが報告することを忘れた場合、
39
 
一般的に後から差し戻してリンクを追加できないことを意味します。
40
 
 
41
 
これに関連したことは関連づけは不変であるという事実です。
42
 
バグがあるコミットによって修正されたものとしてマークされたが、リビジョンがバグを十分に解決しない、
43
 
もしくは後で回帰がある場合、差し戻してリンクを削除できません。
44
 
 
45
 
もちろん、正しいオプションで行うために最新コミットをアンドゥする ``bzr uncommit`` が常に使われます。
46
 
これは正しくないコミットメッセージを訂正するためによく行われ、(たとえば ``--fixes`` を通した)最新コミットに
47
 
記録されたメタデータを訂正するために等しく当てはまります。
48
 
 
49
 
注: 正しくないリビジョンが公開される前に ``uncommit`` を行うのがベストです。