ベースラインという用語を使用しているため、UCMを使用していると想定します。
ストリームでは、ベースラインを逆方向に戻すことはできません。
1つの可能性は、目的のベースラインを基盤として並列ストリームを作成することです。これが最も迅速な方法です。
この新しいストリームを変更した後、新しいリベースを作成してファンデーションベースラインを変更できますが、その新しいリベースが親ストリームからのより新しいベースライン(古いベースラインではない)を使用している場合に限ります。
あなたの特定のニーズのために、私は単純なルールで非UCMスナップショットビューをお勧めします
element * thePreviousBaseline
開発者が持っているために:
- 開発のための彼/彼女の現在のUCMビュー(常にストリームに関連付けられたブランチの最新に設定されます)
- 必要なベースラインに設定された2番目のスナショットビュー。
この2番目のスナップショットビューは、UCMプロジェクトとはまったく関係がなく、ベースラインの「完全」な性質を利用しています(ベースラインが「インクリメンタル」ではなく「フル」に設定されていることを確認してください。「インクリメンタル」の場合、タイプを変更して完全にアップグレードするだけです)
したがって、現在のスナップショットUCMビューのほかに、非スナショットビューが必要な場所に作成できます。
cleartool mkview -snap -tag mylogin_myComponentname_csl_snap -vws myPathToViewStorage myPathToRootView
cd myPathToRootView
cleartool edcs
[add the selection rule: element * myOlderBaseline]
[add the load rule at the end: 'load /myVob_Including_MyComponent]
[save, type 'yes']
これはコンサルテーション/実行には問題ありませんが、パッチを適用する必要がある場合(つまり、書き込み、チェックアウト、およびいくつかのファイルで)、ベースラインごとに1つのUCMストリームにパッチを適用することをお勧めします。
このようにして、ストリームは特定のベースラインのパッチの取り組みを明確に表します。5分ごとに新しいバージョンのアプリケーションを本番環境に移行しない限り、それらの数が多すぎないようにする必要があります...これはお勧めできません;)
要約すると:
- 非UCMスナップショットビューは一意であり、一度に1つの古いベースラインの迅速なコンサルテーション/デバッグに役立ちます。
- パッチ(ソースの変更)の場合、適切な名前の並列ストリームを作成し、適切な基盤ベースラインを使用してから、UCMビューを作成します。アクティビティのいくつかのバグをデバッグするだけでなく修正することもできます。そのバグをより高いストリームに後付けする必要がある場合は、そのアクティビティをメインのIntストリームに配信します。
(注:すべてのバグを常に配信する必要はありません。開発の現在の状態と比較すると、廃止される可能性があります)