Subversionのバージョンブランチのバグ修正がトランクにマージされる方法

Question

私たちはSubversionのブランチとしてソフトウェアバージョンを管理しています。最近のリリースはトランクです。以前にリリースされたバージョンはブランチです（ビルドとリリースごとにタグ付けされています）。開発者が古いバージョンのバグを修正しているときは、その修正をトランクにマージするのは彼の責任です。この手順を逃した場合は、バグが後のバージョンで再び表示されるまで気づきにくいでしょう。それから私たちはデバッグし、それをもう一度修正する必要があります。

マージを監視して完了していることを確認する方法はありますか？

また、より良い結果を得るためにSubversionの分岐を使用するより良い方法があります。

更新：ソリューションには、バグ追跡システムが含まれている必要があります。私たちはJiraを使用し、Jira発行IDでコミットするたびにマークを付けます。これ以上の統合は今実装されていません。

解決策がより良いプロセスを持つ可能性があります。しかし、このより良いプロセスをサポートするためのツールがあれば、それらの存在またはそれらを使用する方法について学びたいと思います。

Answer 1

あなたのバグがバグトラッカーにある場合（そしてそのバグがある場合）、これを使用してバグを追跡できます。あなたのバグトラッカーには、影響を受けるバージョンをマークする方法がいくつかあります。

は、閉じたバグは実際にバグが実際にがサポートされているすべてのリリースで固定 であることを、QA /テストの人々がすべきテストを解決していることを確認します。

SVNのマージトラッキングは、いくつかのを助けることができるが、最終的にそれはあなたを伝えることはできません。

• は、トランク上の無関係な変更によって固定バグであり、この何のパッチは必要ありませんでしたか？
• ブランチからのパッチは、他の変更のためにトランク上で動作しませんでしたか？
• ブランチのパッチはトランクにはまったく適用されませんでしたが、トランクには別のパッチが必要でしたか？

テストは本当にバグがなくなったことを確認する最も良い方法です。 QA /テスト担当者がいない場合は、別の開発者にテストを依頼するか、ソフトウェアテスターを雇うことができます。

Answer 2

バージョン1.5から、SVNはマージされたリビジョンに関する情報をプロパティに入れます。それを見つけてそれを理解できるはずです。ただし、これはがマージされたのリビジョンを通知するだけで、リビジョンをマージするのを忘れたものではありません。

最終的には、ブランチを修正してトランクにマージする責任を負っている人たちのことです。おそらく起こるかどうかを確認する最善の方法は、おそらくは仲間の圧力です。 :)

Answer 3

新しいバージョンのSubversion（私は、1.5または1.6から開始すると思います）はマージトラッキングを持っています。つまり、Subversionは、ブランチ内のどの変更がトランクにマージされたかを追跡します。

あなたはコマンドを使用してトランクにブランチからのすべての変更をマージすることができます

svn co https://server/repo/trunk 
cd trunk 
svn merge --reintegrate https://server/repo/branches/branch_name 
<check merge results, run unit tests, etc> 
svn commit 

は詳細についてSubversion manualを参照してください。

このようにして、ブランチで行われたすべての変更がトランクに到着するようになります。しかし、ブランチからトランクへのすべての変更を取得したくない場合は、svn diffを使用して変更を認識し、マージする変更を選択する必要があります。

Answer 4

まず、これらのことを確認する方法は、バグ追跡システムのバグのエントリのバージョンブランチ上の修正のチェックインとトランクへのマージのチェックを記録することです。バグ追跡システムを持っていない場合は、取得してください。修正プログラムの追跡に役立つだけでなく、バ​​グの状態を追跡する他の多くの問題を解決します。

第2に、別のアプローチを検討することができます。リリースされたバージョンでバグを複製するときは、それをトランクの先頭にも複製してください。ほとんどの場合、それはまだ発生していることがわかります。それをトランクで修正し、その修正をチェックインします。その後、修正を必要とするすでにリリースされているバージョンのブランチに変更をマージします（別の環境のために修正する必要があります）。バグがリリースブランチでのみ発生する場合は、バグが修正されます（トランクにマージする必要はありません）。

Answer 5

チェックイン、ブランチ、マージまたは削除するコードを教えてもらうことは、SVNには何もありません。それは仕事ではありません。それはあなたのコードを格納するバージョン管理ツールを提供しています。

あなたのコードをより良く管理するツールは必要ありません。開発者をより良く管理するための外部システムが必要です。 :)

QA、テスト、バグトラッカーがあります。コードが変更されると、コードに何かが行われたという事実が記録され、さまざまな段階で追跡されます。あなたは通常、誰かが何らかの理由（「私はそれがリファクタリングを必要と感じた」以外）をせずにコードを変更したくないので、追跡ツールはとにかく良いアイデアです。 1つのリリースでバグが修正されたため、このツールを使用して他のバグに修正されていることを確認することができます（適切な場合はリリースに特別な変更を加えたくない場合があります）。

SVNはこれらのツールは、例えば、私のレポは私のMantis bugtrackerを更新します。いくつかの魔法の言葉がチェックインに追加されます（チェックインコメントに "fixed mantis＃1234"と入力すると、変更されたファイルと状態が変更されます）

また、レビューボードなどのツールも統合することができます。変更を加えると、他のユーザーがサインオフするためのリビジョンを投稿したり、サインオフプロセスにバグがマージされているかどうかを確認したり、他のリリースでも修正が必要な新しいバグレポートが作成されます。

この問題は、ここではSVNではなく、開発プロセスにあります。

Answer 6

Subversion開発者自身が使用する戦略を適応させたいかもしれません：ブランチからのリリース、トランクでの開発のほとんどを行います。バグが発見されると、最初にトランク内で修正されてから、修正がトランクからブランチにマージされます。

Answer 7

これは私たちがやっていることです。ちょうどblogged about it - 私たちはCIサーバに特別なビルドをセットアップしました。これは、夜間に、結合されていない変更が存在しないことを保証します。

Answer 8

私は実際にちょっと前にスクリプトを書いて、それを正確に実行しました。私が取り組んでいるプロジェクトでは、同時に複数のブランチが実行されていました。すべてのコミットとマージを追跡するのは非常に困難でした。あなたが2.0リリースブランチを持っているとしましょうhttp://github.com/ccampbell/show-missing-revs

：

あなたは、スクリプトを見つけることができます。この意志出力に何か

cd /path/to/trunk 
sh /path/to/show_missing_revs.sh -b 2.0 -u username (optional) -v (verbose) 

：まだトランクにマージされていない2.0にコミットすべてを見つけるに

r2532 | username | fixing bug with this 
r2631 | username | fixing bug with that 

をこれは私が信じているのsubversion 1.5が必要です。これが便利だと思っていますか？