4

リリースに完全なベースラインを適用しました。例のために。ベースライン「MYProj_2.0.0.20」。

その後、テスト チームは重大な問題を発見しました。その開発チームを修正するために、いくつかの変更を提供しました。

ビルドが完了した後、同じベースライン「MYProj_2.0.0.20」を再度適用しました。ただし、今回は増分ベースラインを適用しました。UCM に従って、ベースライン MYProj_2.0.0.20 は MYProj_2.0.0.20.3452 に変更されました (いくつかのランダム一意にするために最後に番号を付けます）。

ここで、MYProj_2.0.0.20.3452 をリリース ベースラインと見なすと、すべての変更または変更のみが含まれますか ("MYProj_2.0.0.20" と "MYProj_2.0.0.20.3452" の間の差分変更)。

私を明確にしてください。

4

1 に答える 1

4

すべての変更が含まれます。

増分ベースラインを除いて、以下を追加してこれらの変更を計算します。

  • いくつかの変更によって導入された独自の変更 (つまり、「増分ベースライン」とは: 以前のベースライン以降の新しいバージョンにのみ設定されたラベル)
  • 他のすべての変更は、完全なベースラインまで、以前のベースラインによってすでに参照されています

「ベースラインの種類」を参照してください:

  • 完全なベースラインは、コンポーネントのルート ディレクトリの下にあるすべての要素のすべてのバージョンを記録して作成するベースラインです。
  • 増分ベースラインは、最後の完全なベースラインと、最後の完全なベースラインが作成されてから変更された要素のバージョンを記録することによって作成するベースラインです。

( 「 ClearCase ベースラインについて」で詳しく説明されているように、デリバーおよびリベース操作によって自動的に作成される「チェックポイント ベースライン」もありますが、現時点では気にする必要はありません)

そのため、私は常に完全なベースラインを好みます。最後のベースラインが完全なベースラインである場合、すべてのデルタ操作 (「別のベースラインとの比較」など) はより高速です。
増分ベースラインを支持する議論は、作成が高速であるということです (ベースラインを配置するバージョンの数が少ないため)。
しかし、UCM コンポーネントが大きすぎてすべてのバージョンにラベルを付けるのが長すぎる場合は、そもそもコンポーネントが大きすぎる可能性があります。

増分ベースラインはいつでもフル ベースラインにアップグレードできることに注意してください。

次の違いがあることにも注意してください。

  • ベースラインのタイトル (ここでは " MYProj_2.0.0.20": ベースラインはいくつでも " " 置くことができMYProj_2.0.0.20ます)
  • ベースラインの ID (常に一意: " MYProj_2.0.0.20" が既に取得されている場合、ClearCase は最後にいくつかの数字を生成します: " MYProj_2.0.0.20.3452")
于 2012-03-14T06:31:06.653 に答える