依存関係は、コンフリクトを理解するうえでの主要概念です。 ある依存関係で、bar.c-1 がタスク 12 に関連付けられ、bar.c-2 がタスク 25 に関連付けられ、bar.c-3 がタスク 37 に関連付けられ、bar.c-4 がタスク 48 に関連付けられているとします。 この場合、bar.c-4 にはタスク 48 の変更だけでなく、タスク 37、25、および 12 の変更も含まれることになります。
依存関係はプロジェクト構成にどのような影響を与えるのでしょうか。 プロジェクトに bar.c-3 が含まれている場合、タスク 37 はこのプロジェクトに含まれるでしょうか。 答えは「はい」です。ただし、bar.c-3 には直前バージョンの変更も含まれるため、このプロジェクトにはタスク 25 と 12 も含まれます。 タスク 37 がプロジェクトの更新プロパティーに含まれていて、タスク 25 は含まれていない場合はどうなるでしょうか。 これが、コンフリクトの定義に当てはまります。つまり、プロジェクトにはあるが、更新プロパティーにはない変更のことです。
ここまでの説明では、bar.c の例は 1 次元的なものでした。 各タスクを他の複数のオブジェクト・バージョンに関連付けることができる点を考慮すると、依存関係は大幅に複雑化します。 例えば、bar.c-3 に関連付けられているタスク 37 が main.c-6 にも関連付けられているとします。bar.c-3 またはそのいずれかの後続バージョンがプロジェクトに含まれている場合、そのプロジェクトには main.c-6 またはそのいずれかの後続バージョンも含まれていることになります。 さらに、main.c-6 の直前バージョンに関連付けられたタスクがそのプロジェクトに含まれているため、それらのタスクに関連付けられた他のオブジェクトも含まれることになります。 Rational® Synergy は履歴とタスクの関係を分析し、現在含まれている変更と今後含まれるべき変更を依存関係に基づいて判断します。
プロジェクトは、ベースライン・プロジェクト という別のプロジェクトに基づいています。ベースライン・プロジェクトには、そのメンバー・オブジェクトのそれ以前のバージョンの変更がすべて含まれています。 そのため、Rational Synergy は、カレント・プロジェクトとベースライン・オブジェクトとの相違についてのみ、コンフリクトを探すだけですみます。 したがって、コンフリクト分析による各プロジェクト・メンバーの調査は、ベースライン・プロジェクトに含まれるバージョンまで遡るだけですみます。