4

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

Subversionでそのような機能を取得する方法はありますか?タグを付けるリビジョンを指定できることは知っていますが、コードがあり、リリースを実行しようとしてバグを見つけた場合、または誰かが特定の変更を含めるべきではないと判断した場合はどうなりますか。リポジトリとローカルの作業コピーに基づいてタグを作成できることは知っていますが、これには、含めるべきではないファイルの特定のリビジョンをチェックして、タグを作成することが含まれます。「ラベル」を作成する準備ができていれば、不要なファイルのヘッドバージョンにそのラベルを付けることはできません。Subversionのビルドに特定のリビジョンを指定する自動化された方法はありません。これは、ブランチで新しい機能を開発する必要がある場合ではありませんが、リビジョンがトランク(またはタグを作成する場所)にある場合はさらに多くなります。しかし、含まれるべきではありません。元に戻す必要はないかもしれません。変更は適切である可能性がありますが、将来のリリースでは、この現在のリリースではありません。必要な正確なファイルバージョンを含む特定のリビジョンがない場合は、リポジトリと作業コピーから手動で混合して一致させる必要があるようです。

同様の状況で、リリースの一部ではなく、タグ付けする必要のないファイルがSubversionにある場合はどうなりますか。StarTeamでは、すぐに作成できるラベルをそれらに添付しませんが、Subversionでは、ディレクトリ内のすべてのように見えます。そのようなファイルをビルドとタグから除外する方法はありますか?これはsvndumpfilterexcludeの目的ですか?

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

4

5 に答える 5

5

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

于 2009-06-15T00:18:51.710 に答える
2

私があなたの問題を正しく理解していれば、リリース前のある時点 (例えば、このリリースに含めたい主要な機能がすべて完了した時点) で分岐し、マージされるものを慎重に管理することで対処できると思います。その「リリース」ブランチ。「メイントランク」は新しいものは無料です。たとえば、バグが特定された場合、これは (a) メイン トランクで修正され、リリース ブランチにもマージする必要があるかどうかが決定されます。または (b) 枝に固定されています。これは私たちが従うプロセスであり、非常にうまく機能します (ただし、規律とある程度の正式なプロセスも必要です)。

于 2009-06-15T00:45:47.120 に答える
1

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

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

最終的な結果として、maint-1.0 ブランチには、次のビルドで必要な変更のみが含まれます。

于 2009-06-15T15:19:46.530 に答える
1

Subversion では、ソース ツリーのリビジョン全体にアトミックにタグ付けすることしかできません。探している機能には、ソース管理と、変更内容だけでなく、各チケットで変更されたファイルも保持するチケット システムとの間の通信が必要です。

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

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

于 2009-06-15T01:01:14.587 に答える
1

他の答えはほとんどあると思いますが、明確にするために、この状況はリリースブランチで非常にうまく処理されます.

アイデアは、開発の早い段階でトランクからブランチを取得し (または初期のリビジョンから - ブランチ元のリビジョンまでのすべてが必要であることが前提)、通常のマージメカニズムを使用してリビジョンをトランクからリリースに昇格させることです。リビジョン (またはリビジョンのセット) が後で品質が悪いと判断された場合、それらのマージを元に戻すことができます。マージ追跡 (亀ではこれは非常にうまく機能します) は、何が含まれていて、まだ何が残っているかを示し、リビジョンをスキップしたり、順不同でマージしたり、ビルドを機能させるために必要なだけいじったりすることができます。明らかに、競合を手動で解決する必要があるため、スキップして順不同でマージすると、より多くの作業が発生する可能性がありますが、必要に応じて利用できるツールです。

これには、必要に応じて機能セット全体が昇格/削除されるため、個々のファイルを操作するよりも利点があります。さまざまなファイルを手動で探し回って、あちこちから変更を削除する必要はありません。ただし、これには、適切なコミットとコメントが必要です。開発者に「金曜日の午後にコミットして、すべてが安全です」とコミットさせないでください。

于 2009-06-15T20:14:16.827 に答える