これらの問題を解決するには,以下の 1 つ以上の操作を実行します。
「メンバーシップ・コンフリクト」ダイアログ・ボックスを使用して、プロジェクト・メンバーとそのプロジェクト更新プロパティーの間のコンフリクトを確認します。通常、この手順は、どこにコンフリクトが存在するかを確認するために、更新の後で実行します。メンバーシップ・コンフリクトを確認するのに最適な時点は、更新の直後です。この時点であれば、プロジェクト・メンバーがプロジェクト更新プロパティーと一致する状態に更新されているからです。
コンフリクト・メッセージ定義
下表、および表に続くコンフリクト検出の説明では、以下の定義を使用します。
プロジェクト内に存在すると指定されていなかったタスクに関連付けられたオブジェクトが、組み込まれていた。
プロジェクト内に存在すると指定されていたタスクに関連付けられたオブジェクトが、組み込まれていなかった。
オブジェクトのタスク関係が予測と一致していない (例えば、オブジェクトにタスクが関連付けられていなかったか、複数のタスクが関連付けられていた)。
コンフリクト・メッセージ | デフォルトでのコンフリクトの表示 | 説明 |
---|---|---|
コンフリクト・カテゴリー: 余分な変更 | ||
タスクなし | はい | オブジェクト・バージョンは、このプロジェクト内に暗黙的に組み込まれていますが、タスクに関連付けられていません。(明示的に組み込むことができないのは、そのためには、そのタスクをプロジェクト更新プロパティー内に組み込む必要が発生するからです。) |
暗黙的に組み込む | はい | オブジェクト・バージョンは、明示的に指定されませんが、プロジェクト内に組み込まれています。 タスクは、プロジェクト内に暗黙的に組み込まれています。 |
「使用」操作によって組み込む | はい | オブジェクト・バージョンは、明示的に指定されず、暗黙的に要求されません。更新によって選択されていない可能性があります。 |
明示的なオブジェクトからの暗黙的なタスク | はい | タスクに関連付けられたオブジェクトには、複数の割り当てられたタスクがあります。タスクに関連付けられたオブジェクトの少なくとも 1 つが明示的です (つまり、プロジェクト更新プロパティー内に組み込まれています) が、このタスクは明示的ではありません。 |
コンフリクト・カテゴリー: 欠落した変更 | ||
明示的に指定されるが、組み込まれていない | はい | タスクは、プロジェクトによって明示的に指定されますが、組み込まれていません。 |
明示的に指定されるが、組み込まれていない - 新規バージョン | はい | オブジェクト・バージョンは、プロジェクト上で明示的に指定されますが、そのオブジェクトの現在選択されているバージョンの後続バージョンです。 タスクは、プロジェクトによって明示的に指定されますが、組み込まれていません。 |
暗黙的に要求されるが、組み込まれていない | はい | タスクは、暗黙的に要求されますが、プロジェクト内に組み込まれていません。 |
暗黙的に要求されるが、組み込まれていない - 新規バージョン | はい | オブジェクト・バージョンは、暗黙的に要求されますが、プロジェクト内に組み込まれていません。これは、現在選択されているオブジェクト・バージョンの後続バージョンです。 |
複数のタスクによって暗黙的に要求される - 新規バージョン | はい | オブジェクト・バージョンは、プロジェクト内の別のオブジェクトが複数のタスクに関連付けられたときに暗黙的に組み込まれたタスクに関連付けられていたため、暗黙的に要求されます。コンフリクト内のオブジェクト・バージョンは、プロジェクト内に組み込まれておらず、プロジェクト内の現在のオブジェクト・バージョンの後続バージョンです。 |
コンフリクト・カテゴリー: その他 | ||
複数のタスク | いいえ | オブジェクト・バージョンは、このプロジェクト内に組み込まれていて、複数のタスクに関連付けられています。 |
暗黙的に要求されるが、ベースラインの直前バージョンである | いいえ | オブジェクト・バージョンは、暗黙的に要求されますが、ベースラインの直前バージョンです。(暗黙的に組み込まれているため、これはコンフリクトではありませんが、プロセス問題を示している可能性があります。) |
明示的に指定されるが、ベースラインの直前バージョンである | いいえ | オブジェクト・バージョンは、プロジェクト上で明示的に指定されますが、ベースラインの直前バージョンです。(暗黙的に組み込まれているため、これはコンフリクトではありませんが、プロセス問題を示している可能性があります。) |
明示的に指定されるが、オブジェクトがプロジェクト内に存在しない | いいえ | オブジェクト・バージョンは、プロジェクト上で明示的に指定されますが、そのオブジェクトのバージョンがプロジェクト内に 1 つも存在しません。同じプロジェクト更新プロパティーがプロジェクト階層全体で共有されるため、これは通常の状態である可能性があります。 |
暗黙的に要求されるが、オブジェクトがプロジェクト内に存在しない | いいえ | オブジェクト・バージョンは、プロジェクト内に組み込まれているタスクを通じて暗黙的に要求されますが、そのオブジェクトのバージョンがプロジェクト内に 1 つも存在しません。同じプロジェクト更新プロパティーがプロジェクト階層全体で共有されるため、これは通常の状態である可能性があります。 |
コンフリクト・カテゴリー: パラレル変更 | ||
暗黙的に要求されるが、組み込まれていない - パラレル | はい | オブジェクト・バージョンは、暗黙的に要求されますが、プロジェクト内に組み込まれていません。これは、現在選択されているバージョンとパラレルであり、マージが必要である可能性があります。 |
複数のタスクによって暗黙的に要求される - パラレル | はい | オブジェクト・バージョンは、プロジェクト内の別のオブジェクトが複数のタスクに関連付けられたときに暗黙的に組み込まれたタスクに関連付けられているため、暗黙的に要求されます。コンフリクト内のオブジェクト・バージョンは、プロジェクト内に組み込まれておらず、プロジェクト内の現在のオブジェクト・バージョンとパラレルです。 |
明示的に指定されるが、組み込まれていない - パラレル | はい | オブジェクト・バージョンは、プロジェクト上で明示的に指定されますが、プロジェクト内に組み込まれていません。これは、現行バージョンとパラレルであり、マージが必要である可能性があります。 |
コンフリクト・カテゴリー: 問題タスク | ||
除外されたタスクが明示的に組み込まれている | はい | 除外されたタスクがプロジェクトのプロジェクト・グルーピング内に組み込まれています。 |
除外されたタスクが暗黙的に組み込まれている | はい | 除外されたタスクがプロジェクトのプロジェクト・グルーピング内に暗黙的に組み込まれています。 |
完了した修正タスクが組み込まれていない | はい | 問題タスクがプロジェクトのプロジェクト・グルーピング内に組み込まれていますが、completed の正常タスクが組み込まれていません。 |
割り当てられた修正タスクが組み込まれていない | いいえ | 問題タスクがプロジェクトのプロジェクト・グルーピング内に組み込まれていますが、task_assigned の正常タスクが組み込まれていません。 |
タスクによる修正対象タスクが組み込まれていない | はい | 問題タスクがプロジェクトのプロジェクト・グルーピング内に組み込まれていませんが、正常タスクが組み込まれています。 |
タスクとオブジェクトの関係
タスクとオブジェクト・バージョンのセットは、関係を持つことができます。オブジェクト・バージョンのセットを 1 つのタスクに関連付けることができます。これは、それらのオブジェクト・バージョンがまとめて使用され、相互の変更に依存することを示します。1 つのタスクに関連付けられた変更の一部のみがプロジェクトに組み込まれている場合は、プロジェクト・ビルドが失敗することがあります。さらに悪いことに、不正なプロジェクト・ビルドが実行されてしまうこともあります。
例えば、関数シグニチャーを変更する場合、シグニチャー変更を反映するには、その関数を呼び出す他のすべてのプログラムを更新する必要があります。それらの変更をすべてまとめてプロジェクト内に組み込むか、どの変更も組み込まないようにする必要があります。
オブジェクト履歴関係
タスクには履歴関係がありますが、これはオブジェクトの履歴関係とは異なります。通常、オブジェクト履歴は、連続する数値で表されます。タスク履歴は、概念的な関係のみに限定され、タスクに関連付けられたファイル履歴関係に基づいています。タスクは、変更を完了するために必要なファイルをグループ化します。そのため、タスク履歴関係では、変更の現在のセットが変更の以前のセットに依存します。
main.c オブジェクトには 5 つのバージョンがあります。各バージョンはそれぞれ異なるタスクに関連付けられています。(各バージョンに関連付けられたタスク番号がオブジェクト・バージョンの下に示されています。)
Rational® Synergy は、1 つのオブジェクト・バージョンへの変更には、そのすべての先行オブジェクト・バージョンへの変更が含まれていると見なします。したがって、この例では、バージョン 3 にはバージョン 2 および 1 からの変更が含まれていると見なされます。
例えば、バージョン 2 内の関数のシグニチャーを変更した場合、バージョン 3、4、および後続のすべてのバージョンには、そのシグニチャー変更が組み込まれます。変更は、先行する他の変更の上に階層化されます。別の変更の一部を取り消す変更であっても、その履歴バージョンの上に階層化されます。しかし、main.c-3 内の変更は、main.c-2 に対して行われたものであるため、変更はこのバージョンにのみ適用されます。
タスク依存関係
さらに、バージョン 3 にはバージョン 1 および 2 からの変更が含まれているため、バージョン 3 に関連付けられたタスクは、バージョン 1 および 2 に関連付けられたタスクに依存します。この例では、タスク 58 はタスク 23 および 14 に依存します。
明示的に指定される更新プロパティー
main.c-4 を含むプロジェクト myproj-sue について考えます。
このプロジェクトのプロジェクト・グルーピング内にタスクがある場合、プロジェクトは、そのタスクに関連付けられたオブジェクトを組み込むように明示的に指定しています。例えば、myproj-sue 更新プロパティーにタスク 72 および 23 が組み込まれている場合、プロジェクトは、タスク 72 および 23 に関連付けられたオブジェクト・バージョンを組み込むように明示的に指定しています。上の図で、プロジェクトがタスク 72 および 23 を明示的に指定している場合、プロジェクトは、オブジェクト・バージョン main.c-4 および main.c-2 も明示的に指定しています。
main.c-4 には main.c-2 からの変更が含まれ、タスク 72 はタスク 23 に依存することに注意してください。
プロジェクトが更新されるときには、明示的に指定されるオブジェクト・バージョンが候補になります。更新されるときには、最も適切な候補 (通常は最新の候補) が選択されます。したがって、この例では、myproj-sue は、タスク 72 および 23 を使用して、main.c-4 および main.c-2 という候補リストを決定します。最新の候補である main.c-4 が選択されます。したがって、プロジェクトは、main.c-4 および main.c-2 の両方からの変更を組み込みます。同様に、タスク 72 およびタスク 23 の両方からの変更が含まれます。
暗黙的に指定される更新プロパティー
myproj-sue プロジェクトには main.c-4 が含まれるため、このプロジェクトには、そのプロジェクト更新プロパティーが明示的に指定したタスク 72 が含まれます。また、main.c-3 が main.c-4 の直前バージョンであるため、main.c-3 にも依存します。さらに、main.c-3 に関連付けられたタスク (タスク 58) にも依存します。
しかし、タスク 58 (および main.c-3) が myproj-sue 更新プロパティー内で明示的に指定されていないが、その履歴関係を通じて何らかの方法で変更が組み込まれている場合は、タスクおよびオブジェクト・バージョンの両方がプロジェクト内で暗黙的に指定されています。暗黙的に指定されるタスクに関連付けられたオブジェクトは、プロジェクト内に自動的には組み込まれません。
コンフリクト
プロジェクトのリリースを準備しているとします。リリースにタスク 72 および 23 が含まれるように指定しますが、タスク 58 は指定しません。ビルドの後で、タスク 58 がアプリケーション内に組み込まれています。Rational Synergy は、要求しなかったタスクが組み込まれていることを警告できます。この状態をコンフリクト と呼びます。
さまざまなタイプのコンフリクトがあります。プロジェクト内で main.c-5 を手動で使用したが、プロジェクト更新プロパティーがタスク 86 を明示的に指定せず、明示的に指定したその他のタスクがタスク 86 に依存しない場合、一種のコンフリクトが発生する可能性があります。Rational Synergy は、1 つのオブジェクト・バージョンがプロジェクト内で使用されているが、そのタスクが明示的に指定されていないことを認識し、警告できます。
コンフリクトの中には、他のコンフリクトよりも重大度が高いものがあります。
例えば、あるチームでは、ファイルの 1 つのバージョン内で複数のバグを修正しないことになっています。さらに、このチームの各開発者には、自分が変更する各オブジェクト・バージョンにタスクを 1 つのみ関連付けるという要件があります。あるオブジェクト・バージョンに複数のタスクが関連付けられている場合は、そのことを認識して、この要件に関して開発者に注意を喚起できるようにする必要があります。しかし、リリースを準備しているソフトウェアには必要な変更がすべて含まれているため、これは重大なコンフリクトではありません。
より重大なコンフリクトは、暗黙的に組み込まれているオブジェクト・バージョンがどのタスクにも関連付けられていない場合です。
Rational Synergy は、両方のタイプのコンフリクトに関して警告できます。
パラレル・コンフリクト
最も重要なタイプのコンフリクト検出の 1 つは、パラレル・オブジェクト・バージョンの検出です。
プロジェクトが変更を明示的に指定したが、その変更が組み込まれていない場合、これは重大なコンフリクトです。例えば、2 つのパラレル・オブジェクトが 2 つの異なるタスクに関連付けられていて、両方のタスクが明示的に指定されている状態について考えます。この例では、myproj-sue に bar.c-3 が含まれていると想定します。bar.c オブジェクトには、下図に示す履歴関係およびタスク関連付けがあります。
myproj-sue プロジェクト更新プロパティーは、タスク 58 および 86 を組み込むように指定します。このプロジェクトには、タスク 58 に関連付けられた bar.c-3 のみが組み込まれています。タスク 86 に関連付けられた bar.c-2.1 はパラレル・ブランチであるため、2 つのバージョンを同時に組み込むことはできません。要求した両方の変更を含む 1 つの bar.c バージョンは存在しません。必要なオブジェクト・バージョンがプロジェクトから欠落しているため、このコンフリクトは重大です。
パラレル・コンフリクトとして表される欠落した変更もありますが、他のタイプの欠落した変更も存在します。
欠落した変更
myproj-sue プロジェクト内に bar.c-2.1 を手動で組み込んだ場合にどのような状態が発生するかを考えます。明示的に指定されていても、タスク 58 および 86 の変更は欠落している可能性があります。これらは、プロジェクト内の現在のオブジェクトのバージョンよりも新しいからです。
この変更は、明示的に指定されていますが、欠落しています。プロジェクト更新プロパティー内に組み込まれているタスクでこれらの変更を探した場合に、欠落した変更に気付くこともあります。他のタイプのコンフリクトは、検出するのがさらに困難です。
タスク 86 および 58 ではなくタスク 86 および 36 を組み込むように myproj-sue 上のプロジェクト更新プロパティーを再表示した場合、タスク 58 は明示的に指定されなくなります。タスク 86 は main.c-5 に関連付けられていて、その直前バージョンである main.c-4 はタスク 72 に関連付けられています。したがって、タスク 86 はタスク 72 を暗黙的に組み込みます。プロジェクトに main.c-5 が組み込まれている場合は、両方の変更が組み込まれ、すべてが正常です。しかし、bar.c についてはどうでしょうか。bar.c-2.1 はタスク 86 に関連付けられているため、明示的に指定されます。bar.c-3 はタスク 58 (プロジェクト内に暗黙的に組み込まれています) に関連付けられているため、暗黙的に指定されます。したがって、この場合も、プロジェクトが要求したすべての変更を含む bar.c のバージョンは存在しません。
大規模なコンフリクト検出
次に、数百個のオブジェクト・メンバーを含むプロジェクト (それぞれのメンバーには、多数のバージョンを含む履歴があります) および数百個のタスクから構成されるリリースを考えます。チームがどれほど注意深く作業しても、プロジェクトが大きいほど、エラーの機会は多くなります。一般的なエラーには、パラレル開発 (マージを忘れた場合) または人的エラー (オブジェクト/タスク関連付けを忘れた場合) に起因するコンフリクトが含まれます。解決策は、エラーを検出し、ビルドの前にそれらを修正することです。Rational Synergy は大規模なプロジェクト上のコンフリクトを検出できるため、チームは、コンフリクトが問題に発展する (つまり、ビルドを妨害する) 前にコンフリクトを解決できます。
Rational Synergy は、履歴関係とタスク関係に基づいて、24 種類のコンフリクトを検出できます。その他のコンフリクトも存在することがありますが、重大ではありません。それらのコンフリクトはデフォルトでは表示されないため、ユーザーは、ソフトウェアの整合性に影響するコンフリクトに集中できます。しかし、デフォルトで表示されるコンフリクトを変更する場合は、CM アドミニストレーターが conflict_parameters モデル属性を変更することにより変更できます。
コンフリクトがあるかどうかを判別するためにプロジェクトが分析され、コンフリクトが表示されます。
プロジェクトのサイズおよび特性によっては、コンフリクト検出には時間がかかることがあるため、コンフリクトを表示するのに最適な時点を計画してください。通常、ビルド・マネージャーは、ビルド管理プロジェクトを更新するごとにコンフリクトを表示します。開発者のプロジェクト内に、問題の原因となっているパラレル・バージョンまたはその他のコンフリクトが含まれている疑いがある場合は、コンフリクトを表示することをお勧めします。
プロジェクトを検索するには、オブジェクトの検索を参照してください。