プロジェクトの新しいバージョンで作業したい場合は、新しいバージョンを定義できます。これにより、現在および/または将来のバージョンにバグを割り当て、バグが修正されるバージョンを示すことができます。これにより、作業に優先順位を付けることができ、ユーザーはいつ修正される予定かを確認できます。詳細については、ドキュメントのセクション 3.4.3を参照してください。
Subversion を Bugzilla に関連付けるには、ScmBug、または Eclipse のMylynなどの他の統合を使用して、Subversion と Bugzilla の関係を管理できます。タスクと。developerworksに Mylyn の紹介があります。
関係を設定して変更をコミットすると、統合によってタスク番号がリビジョンに関連付けられます。
Subversion でタグ付けを行うときに Bugzilla バージョンの作成を自動化したい場合は、以下にいくつかのヒントがありますが、タグの作成は製品がビルドされて使用可能になったことを意味しないため、手動で行う方がよいでしょう。ユーザー (フックを拡張してパッケージも作成しない限り)。
Subversion のpost-commit フックを設定できます。このフックは、変更をコミットするたびに呼び出されます。コミットのタイプがタグ ディレクトリへのコピーであるかどうかを確認し、APIを介して Bugzilla を呼び出して新しいバージョンを作成できます。
すべてのタグに対してバージョンが作成されないように、リリース タグにいくつかの規則を定義する必要があります (たとえば、タグが「release」で始まる場合は API を呼び出します)。
Python Subversion 拡張機能pysvnは、フック処理を簡素化するのに役立ちます。
Subversion のドキュメントには、作業を開始するのに役立つサンプル スクリプトもいくつかあります。
私の理解では、Bugzilla のバージョンはバグが見つかったバージョンです (ドキュメントから: バグが存在した最も古いバージョン)。
私の現在のやり方は、将来のバージョンごとにバグを追跡することです。これは、IIRC が Mozilla の時代に処理された方法でした。
Bugzilla はそれ以来、高度な検索の検索基準としても使用できるターゲット マイルストーンやフラグなどの概念を導入しました。