問題タブ [clearcase-ucm]

Rational ClearCase v。7.0.1.1をUCMで使用すると、ClearCaseの「ストリームから代替ターゲットへの配信」機能を使用するときに問題が発生します。

1つのプロジェクト統合ストリームとそれから派生した2つの開発者ストリームAとBがあると想像してください。次に、ストリームAのファイルを変更します。ストリームBを所有するdelevoperが、ファイルを統合ストリームに配信しなくても作業を使用できるようにしたいので、ストリームAから代替ターゲットストリームBに配信します。

ここまでは順調ですね。ファイルに別の変更を加えますが、ストリームB開発者はこの変更を必要としないため、ファイルを配信しません。

しばらくして、作業をメインの統合ストリームに配信します。これは問題なく機能しますが、ClearCaseがマージを「マージ済み（トリビアル）」ではなく通常の「マージ済み」としてマークするのはなぜかと思います。ファイルに変更を加えたのは私だけです。

配信後、メインの統合ストリームに新しいベースラインが作成されます。

本当の問題は、開発者Bが自分のストリームをリベースしようとしたときに発生します。開発者Bはファイルに変更を加えたことがないので、対話が不要な簡単なマージになると思います。しかし、何が起こるかというと、開発者Bは、そのファイルのマージの競合をグラフィカルに解決することを余儀なくされ、統合ストリームのベースバージョン、私が彼に配信したバージョン、および統合ストリームに配信したバージョンのいずれかを選択できるようになります。

マージを解決してリベースを完了した後、開発者Bがメインの統合ストリームへの配信を実行したい場合、混乱が続きます。私が最初に彼に提供したアクティビティとは別に、彼はrebase_...という名前のアクティビティを提供するように提案されています。

ここで何かが足りませんか？ClearCaseを誤って使用していますか、それともこれは既知の制限/バグですか？この機能を使った経験はありますか？

よろしくお願いします！

1月

I have 3 projects A, B based on A, C based on A.

Changes A should first be merged to B and then from B to C. There are also changes in B not affecting A but some of this changed need to be merged in C.

There some changes from A which have been incorrectly merged directly from A to C bypassing B. (I'm using the word "merged" because we needed to merge those manually because automatic delivery would include a bunch of activities we don't need to deliver to B and C).

この問題を解決するには、B ではマージされていないが、C でマージされた変更を B でマージする必要があります。A からマージすることによって作成された C のすべてのバージョンを一覧表示する方法を探しています。これらのファイルの変更を B にマージできることを確認しました。

ありがとう

私は問題の解決策を探しているのではなく、将来起こりうる問題を回避しようとしているので、質問はあまり明確ではないかもしれません.

プロジェクト AB と C があり、B と C は A の異なるベースラインに基づいているとします。B と C の間で、B から C へ、またはその逆方向でマージしても問題ありませんか?後で問題が発生しませんか?

私の特定の状況では、A から B、B から C にマージされたバージョンがあり、C から B にマージしたいと考えています。トランク内の A では、C はインストール固有であり、B は顧客固有です。お客様が新しいビルドを展開した場合、最終的には C を放棄します。しかし、現在 (誤って) いくつかの変更が B を迂回して A から C にマージされているという状況があります。変更は A -> B -> C に移動する必要があります。問題は、A から C へのいくつかのマージが重要なマージであり、このバージョンでは、C から B にマージするだけの方が簡単なようです。大丈夫ですか？

ありがとう！

UCMプロジェクトごとに統合と1つの共通の開発ストリームがあるモデルを採用しています。プロジェクトAはトランクです。プロジェクトBは、プロジェクトAの統合ストリームのベースラインBL1で作成されたプロジェクトAのブランチです。プロジェクトAの開発ストリームは、統合ストリームでベースラインBL2を使用して後でリベースされました。したがって、BL2はBL1と比較して新しいベースラインです。

問題は、プロジェクトのA開発ストリームとプロジェクトのB開発ストリームの基礎ベースラインが異なる（プロジェクトのA開発ストリームの基礎ベースラインが新しい）という事実が、プロジェクトのB開発ストリームからプロジェクトのA開発ストリームへのマージに影響するかどうかです。

違いが非常に大きいため、重要なマージが多数発生することは理解していますが、この状況でCCに根本的な問題が発生しないことを確認する必要があります。

ありがとう！

私たちはプロジェクトを持っており、欠陥の修正を除いて大きな変更を加えることなく、安定したコードベースに新しい機能を追加しようとしています。計画では、しばらくの間 (おそらく 1 か月間) 新機能を個別に開発せず、中間ビルドとテストを行い、機能が完成して品質が許容できるようになったら、新機能のコードをメイン ブランチにマージします。

問題は、次の 2 つのシナリオのどちらが Clear Case に関して優れているかです。

1. 現在のプロジェクトの統合ストリームのベースラインに基づいて新しいプロジェクトを作成し、この別のプロジェクトで新しい機能を開発し、新しいプロジェクトの統合ストリームに中間配信して、統合ストリームからビルドします。そして最終的に、新しいプロジェクトの統合ストリームからメイン プロジェクト (dev または int) への変更を配信します。

2. メイン プロジェクトでストリームの階層を使用する: メイン プロジェクトで統合ストリームの子ストリーム (temp_int と呼びます) と temp_int の子ストリーム (temp_dev と呼びます) を作成します。temp_dev で新機能を開発し、temp_int への定期的な配信と temp_int からのビルドを行ってから、temp_int からメインの統合ストリームに新機能を配信します。

同じレベル (つまり、同じ親ストリーム) の階層に 2 つの Clearcase UCM ストリームがあります。2 つの子ストリームが両方とも同じ親ベースラインにリベースされている場合、それは

• 両方のストリームのアクティビティを親に配信する (一方、次に他方)

次と同等です。

• 1 つの子ストリームのアクティビティを別の子ストリームに配信し、1 つの子ストリームを単に親に配信する

これは実際に本当ですか？すべての配信に対して手動/ユーザーが選択したマージが同じ方法で行われると仮定すると、そうあるべきです。

私の同僚と私は、ClearcaseUCMを使用してアイデアをストリーミングする必要があります。現在、管理者は機能的なソフトウェアパッケージごとにストリームを作成しており、各パッケージにはインターフェイスが定義されており、階層化されたアーキテクチャ内に存在します。開発者は、作業しているパッケージに応じて子ストリームを作成し、コードを個別に開発しようとしますが、通常、初期開発時に他のパッケージに依存します。これにより、統合グループはシステムビルドを作成し、開発者はこれを使用して、ソフトウェアを開発し、依存関係（zipファイル、パッチなど）を手動で取り込むための適切な環境を作成しました。

私の主張は、これは間違っており、UCMの使用目的ではないということですが、私の信念を確認するには、UCMに精通した誰かが必要でした。

ストリームは機能的な観点から作成する必要があると思います（各パッケージは何らかの機能を果たしますが、複数のアーキテクチャパッケージは、「ABC」と呼ばれる顧客機能の実現に貢献します）。次に、機能「ABC」の初期開発を行っている各アーキテクチャコンポーネントのコンポーネントがストリームに追加されます。関数「ABC」のすべての開発者は、その関数を完了するためにストリーム（または子ストリームのセット）で作業するようになりました。完了すると、各UCMコンポーネントのベースラインが作成され、UCMの観点からコンポーネント間に「バインディング」は存在しません（アクティビティレコードが原因で、これがUCM内で何らかの形で発生する可能性があると誰かが主張しました）。

注：この方法で永遠に作業しないことに同意しますが、インターフェースが一般的に変更される初期開発では、すべての機能のすべてのインターフェースを実装していないため、複数のコンポーネントをストリームで連携させるのが最も理にかなっています。後で、各パッケージが別のパッケージの変更から独立している「アーキテクチャパッケージ中心」の作業方法に移行できます。

考え？長い投稿で申し訳ありませんが、詳細が必要だと感じました。

変更管理と障害追跡のために Rational ClearQuest を実装することを考えています。Rational ClearQuest と Rational ClearCase を統合すると、アクティビティは Rational ClearQuest から発生します。

現在、Rational ClearQuest の実装にはプロセスの関係で時間がかかるため、開発者側からアクティビティの作成を削除することを考えています。管理者が各開発者のアクティビティを作成できるようにすることを考えています。

ここで、いくつかの懸念があります. 管理者がアクティビティを作成し、保護コマンドを使用してアクティビティとグループの所有者を変更した場合、それで十分ですか? このアクティビティは他の開発者にも使用されますか? 活動は作品なので、これは共有できますか？

これについて明確にする必要があります。

ありがとう。

私たちは、Rational ClearCase UCM モデルのストリーム構造を考え出しました。

最近、コード ベースを新しいセットアップに移行しました。3 つの異なるコード ベース、つまり 3 つの物理的なコード ベースがありました。

移行プロセス:

最初に本番コードを移動し、アクティビティを作成し、アクティビティを統合ストリームに配信し、ベースラインを作成しました。
次に、uat コードがアクティビティを作成し、そのアクティビティを統合ストリームに配信し、マージ中にコントリビューター 2 からの変更を選択して、uat の既存のコードを保持し、ベースラインを作成しました。開発環境の同じプロセス。

現在、統合ストリームには、開発ベースラインである最新のベースラインがあります。
これで、それぞれの環境でリリースが行われる prd と uat 用の他の 2 つのストリームができました。

私は今私の開発ストリームを持っています。アクティビティを作成し、いくつかの変更を加えます。ここで、これらの変更を uat 環境にプロモートする必要があります。インテグレーション ストリームに変更を配信すると、マージは完了しますが、開発ベースライン上で行われます。多くの開発アプリが望ましくない uat にリベースされるため、uat にリベースしたくありません。

uat 環境 (uat ストリーム) への変更を促進するにはどうすればよいですか。親切にアドバイス。

構成管理パターンに関する質問 (Rational ClearCase UCM を使用)

メインライン アプローチを使用する場合、次の方法で新しいリリースを作成します。

• メインラインからリリース 1 を作成する
• ある時点でベースライン リリース 1、リリース 1 をメインラインに配信
• メインラインからリリース 2 を作成する
• ある時点でベースライン リリース 2、リリース 2 をメインラインに配信
• メインラインからリリース 3 を作成する
• 等...

パス名がetc/main/release 3/latestの代わりにあるため、非常にうまく機能し/main/release 1/release 2/release 3/latestます...

ただし...リリース1に新しい要素があり、それを後のリリースに伝播する必要がある場合、メインラインはすでにリリース4などにあるため、メインラインを使用できません。

私にできる唯一のことは、リリース 1 からリリース 2 に直接配信/マージすることです。
悪い点は、パス名が/main/release 1/release 2/latestそのファイル (およびおそらくそれ以降のリリース) のパス名になることです。それは、メインラインのアプローチと一致していないと思います。

私は何を間違っていますか？

相互投稿: http://www.cmcrossroads.com/forums?func=view&catid=31&id=99369#99369 相互投稿: https://www.ibm.com/developerworks/forums/thread.jspa?threadID=330226