Subversionに、次のリリースに含まれるファイルを示す "ラベル"を作成します。

Question

バージョン管理用にStarTeamを使用していましたが、Subversionに移行しています。私はSubversion bookを読んできましたが、StarTeamはSubversionにはないという大きな特徴の1つ、つまりラベルの概念があるようです。私はSubversionがラベルを持っていることを知っていますが、StarTeamでは何か違う意味です。 StarTeamでは、一連のファイルに「準備完了」というラベルを付けてから、それらをチェックして特定のリリースに含めることができます。次に、そのファイルにどのファイルが含まれているかを示すフリーズされたラベルを作成できます（Subversionタグに似ていますが、ディレクトリ内のすべてではなく、特定のリビジョンにあります）。

Subversionでこのような機能を利用する方法はありますか？タグを付けるリビジョンを指定できるのは分かっていますが、コードを持っていてリリースをやろうとしているときに何が起こり、バグが見つかった場合や、特定の変更が含まれてはならないと判断した場合です。リポジトリとローカルの作業コピーに基づいてタグを作成することができますが、これには含まれないファイルの特定のリビジョンをチェックし、タグを作成する必要があります。 "ラベル"を作成する準備ができていれば、不要なファイルの先頭バージョンにそのラベルを付けることはありません。 Subversionのビルドの特定のリビジョンを自動的に指定する方法はありません。これは、ブランチで新しい機能を開発するべきではありませんが、リビジョンがトランク内にある場合（またはタグを作成する場所）は含まれません。それは元に戻す必要はないかもしれません - 変更は適切かもしれませんが、将来のリリースでは現在のものではありません。あなたが必要とする正確なファイルバージョンで特定のリビジョンを持っていない場合は、リポジトリと作業コピーから手動でミックスして一致させる必要があるようです。

同様の状況で、リリースに含まれていないタグが付いていないファイルがSubversionにある場合はどうなりますか？ StarTeamでは、ビルド準備完了ラベルを添付することはありませんが、Subversionではディレクトリ内のすべてのものに見えます。ビルドやタグからそのようなファイルを除外する方法はありますか？これは何ですかsvndumpfilter excludeは？

要するに、特定のファイルの特定のリビジョンのみをタグに含めるか、リポジトリ内の特定のリビジョンか、リポジトリ内のファイルと作業コピーを手動で組み合わせる必要があります？

Answer 1

私が問題を正しく理解していれば、リリース前のある時点（たとえば、このリリースに含まれるすべての主要機能が完了した時点）でブランチすることで処理できると信じています。その "リリース"ブランチにマージされるもの"メイントランク"は新しいもののために自由です。たとえば、バグが識別された場合、これは（a）メイントランク上で固定され、次にリリースブランチにマージする必要があるかどうかの決定が行われます。 （b）支店に固定してください。これは私たちが従うプロセスであり、それは非常にうまくいく（しかし、規律と一定量の正式なプロセスも必要とする）。

Answer 2

特定のリビジョンで分岐またはタグ付けします。ブランチを変更して、そのブランチに必要な特定の変更や更新を含めることができます。ブランチしたら、必要な数のファイルを変更して、そのブランチだけを更新することができます。ですから、個別にファイルを古いリビジョンに更新し、ブランチにコミットすることができます。

Answer 3

Subversionでは、ソースツリーのリビジョン全体を原子的にタグ付けすることができます。あなたが探している機能は、ソースコントロールと、変更するチケットだけでなくチケットごとに変更されたファイルも保持するチケット発行システムとの通信が必要です。

Tracは、たとえば、コミットログを解析しますコミットログの構文＃を使用して、各リビジョンを任意の数のチケットに関連付けることができます。

新しいリリースに関連付けられたチケットを維持し、デルタリリースパッケージに含めるファイルを計算するモジュールが必要になります。

Answer 4

私はあなたの最善の策は、枝を使用することだと思う。新しいリリースでの作業の仕方によっては、アクティブな開発に使用されないクリーンなブランチを作成するか、トランクをクリーンに保ち、アクティブな開発のためにブランチを使用することができます。その後、ファイルが完成し、次のビルドの準備ができたら、それらのファイル変更をクリーンブランチにのみマージします。

たとえば、トランクで作業していて、バージョン1.0をリリースしているとします。次にmaint-1.0というブランチを作成し、誰も触れません。私たちはトランク内で開発を続け、特定の機能や機能が終了すると、変更されたファイルをmaint-1.0ブランチに移動します。 2つの作業コピーがあり、変更されたファイルを単にコピーする必要があるかもしれないことに注意してください。実際のマージを実行すると、特定のファイルだけでなく、すべての変更がマージされます。

結果として、maint-1.0ブランチでは、次回のビルドで必要な変更のみが行われます。

Answer 5

私は他の答えはかなりあると思いますが、明示的にするために、この状況はリリースブランチで非常にうまく処理されます。

アイデアは、開発の早い段階でトランクからブランチを取ることです（初期のリビジョンから、あなたがブランチするすべてのリビジョンまでを望むということです）。そして、通常のマージメカニズムを使用してリビジョンをトランクを解放する。リビジョン（またはリビジョンセット）が後に品質が悪いと判断された場合、それらのマージを元に戻すことができます。マージトラッキング（これは本当にうまくいく）は、何が含まれているのか、何が残っているのかを示しています。リビジョンをスキップして順不同でマージし、ビルド作業に必要なだけ混乱させることができます。明らかに、スキップして順不同でマージすると、手動で競合を解決する必要があるため、より多くの作業を作成できますが、必要なときに利用できるツールです。

これは、フィーチャセット全体が必要に応じて昇格/削除されるため、個々のファイルを扱う場合に比べて利点があります。手動で別のファイルを検索して変更を削除する必要はありません。しかし、これはあなたにはまったくコミットとコメントが必要です - あなたの開発者が "金曜日の午後のためにコミットするので、すべてが安全です"とコミットすることはできません。