CC-CQ 統合を有効にしています。
レコード 1 がユーザー A に承認され、レコード 2 がユーザー B に承認されているとします。ユーザー B が所有者であるレコード 2 を使用していくつかの変更をチェックインしようとしたとき (チェックイン ウィンドウでレコード 2 を選択して) 、実際のチェックインはレコード 1 で発生しましたが、これは当てはまりません。これがどのように発生し、どのように追跡できるかを理解するのを手伝ってください.
CC-CQ 統合を有効にしています。
レコード 1 がユーザー A に承認され、レコード 2 がユーザー B に承認されているとします。ユーザー B が所有者であるレコード 2 を使用していくつかの変更をチェックインしようとしたとき (チェックイン ウィンドウでレコード 2 を選択して) 、実際のチェックインはレコード 1 で発生しましたが、これは当てはまりません。これがどのように発生し、どのように追跡できるかを理解するのを手伝ってください.
これも共有ストリーム構成のように聞こえます.... 一般に、これがオプションであることさえあるのは、チェックインが共有ストリームにある場合だけです。単一ストリーム プロジェクトまたは共有ストリームのいずれか。ClearCase のバージョンと使用しているインターフェイスについても教えてください。2 つの Eclipse ベースのリモート クライアント、ClearCase エクスプローラー GUI、およびさまざまな開発ツールの統合があり、それらの動作は微妙に異なる場合があります。
Record 1 と Record 2 の両方に依存するユーザー C による変更がない限り、これは発生しないはずです。レコード 1 と 2 の両方。
真にスタンドアロンのコンポーネントを設計することは、この種の競合を解決するのに役立ちますが、完全に排除することはできません。