ユーザーヘルプ > 変更パッケージ内の作業単位のグループ化 > CP の適用と CP の再同期の高度な概念 > 差分変更の計算のしくみ
  
差分変更の計算のしくみ
差分変更は、ターゲット プロジェクトがソース プロジェクトと等しくなるようにするために、メンバーまたはサブプロジェクトごとにそれらの差分変更を表す 1 つの操作を計算することで特定されます。
CP の適用コマンドでは、差分変更はリポジトリ内の既存のアーティファクトに対応している必要があります。たとえばメンバーの場合、差分変更は、そのメンバーのアーカイブ内の既存のリビジョンに対応している必要があります (ただし、差分変更がそのアーティファクトの除外である場合は除く)。差分変更を (マージが必須であるなどの理由で) 既存のアーティファクトに解決できない場合、伝播は失敗し、代わりに CP の再同期コマンドを使用して手動でタスクを実行する必要があります。
CP の再同期コマンドでもメンバーまたはサブプロジェクトごとに 1 つの操作が計算されますが、CP の適用の場合とはしくみが異なります。CP の再同期の場合は、サンドボックスのコンテキストで処理が行われるため、伝播変更パッケージのサブミット時に、メンバーのアーカイブに新しいリビジョンを作成するためにチェックインされるサンドボックスでマージを行うことができます。ただし、マージの複雑さに関して制限があります。たとえば、メンバーの 1 つの操作を生成するために連続していない 2 つ以上のリビジョンのセットをメンバーのアーカイブからマージする必要がある場合は、この操作は失敗します。ほとんどの場合、それでも変更を伝播できますが、伝播をより細かく分割して順番に実行する必要があります。
ターゲットに差分変更が存在する場合の影響
Windchill RV&S で差分変更が特定されるしくみを理解するうえで把握しておく必要がある重要な要素は、Windchill RV&S では、ターゲットのメンバーリビジョンが既に差分変更で伝播する必要があるリビジョン (またはそれ以降のリビジョン) である場合、ソースからターゲットへの変更の伝播が既に完了していると見なされるということです。これは特に次の 2 つの場合で意味を持ってきます。1 つは、ソース プロジェクト ツリーからターゲット プロジェクト ツリーに一度伝播した変更を再度伝播する場合で、もう 1 つは、メンバーリビジョンを現在のものよりも古いリビジョンに更新する変更を伝播する場合です。どちらの場合も、Windchill RV&S では、必要な変更が既にターゲットに反映されていると見なされ、処理は行われません。次に例を示します。
ソースのプロジェクト階層ではメンバー bar.txt のリビジョン 1.6 を開発者が保持していますが、ターゲットのプロジェクト階層にあるこのメンバーのリビジョンは 1.5 です。ソース階層では、開発者のジョンは、bar.txt のメンバーリビジョンの更新操作を行ってリビジョン 1.4 に戻すエントリを含む、新しい変更パッケージ 1:1 を作成します。別のユーザー、メアリーが変更パッケージの適用 (または変更パッケージの再同期) を使用してこの変更パッケージをターゲットに伝播させようと試みる場合、ターゲットは既に変更されているため (リビジョン 1.5 は暗黙的に 1.4 の上にビルドされるため)、Windchill RV&S は何もしません。このユーザーがターゲットのメンバーリビジョンを強制的に 1.4 に戻す場合は、手動で実行する必要があり、CP の適用 (または CP の再同期) を使用して実行することはできません。
ターゲットにどの変更が既に反映されているかは、リビジョンの番号に基づいて判断されます。これらの変更は、コマンドのプロセスでは必ず無視されるほか、バックフィルのプロセスでも無視されます。
伝播の際に使用される変更
Windchill RV&S で差分変更が特定されるしくみを理解するうえで把握しておく必要があるもう 1 つの重要な要素は、伝播の際に考慮されるのはプロジェクトのメンバーやサブプロジェクトの構成に実際に影響する変更だけであるということです。たとえば、変更パッケージを使用してアーカイブに新しいリビジョンをチェックインする際に、それらの新しいリビジョンによってプロジェクト内のメンバーリビジョンが更新されないように指定することができます。そうすると、それらのエントリはソース プロジェクトのメンバー構成を更新しないため、その変更パッケージをターゲットに伝播するときに無視されます。
仮想バケットにグループ化される差分変更
Windchill RV&S は、伝播される変更パッケージ (ユーザーまたはバックフィルから選択するよう指定されたユーザーが明示的に選択した変更を含む) の一覧にあるそれぞれのメンバーまたはサブプロジェクトに対して、内部的に仮想のバケツを作成して、差分変更を処理します。Windchill RV&S は、それらの変更パッケージ内のすべての変更パッケージ エントリを、発生した順番に 1 つずつ確認し、対応するバケツにエントリを追加します。変更は次の方法でグループ化されます。
メンバーの場合は、リポジトリ内のメンバーのアーカイブの場所がバケットのプライマリ ID になります。
サブプロジェクトの場合は、サブプロジェクトの基となるプロジェクトのリポジトリ内の標準の場所がバケットのプライマリ ID になります。
移動 (および名前変更) されたメンバーおよびサブプロジェクトの場合は、移動 (または名前変更) されたメンバーまたはサブプロジェクトの場所 (および名前) が、古い方も新しい方もバケットによって追跡されます。
Windchill RV&S がソース プロジェクト ツリーからターゲット プロジェクト ツリーに変更を伝播するためには、ソースの各メンバーまたはサブプロジェクトに対応するターゲットのメンバーまたはサブプロジェクトを見つける (あるいは必要に応じて追加または作成する) 必要があります。Windchill RV&S
サブプロジェクトの場合は、ターゲットにないことが確認されると、対応するバリアント サブプロジェクトがすぐに (伝播する差分変更を計算する最初のフェーズで) ターゲットに作成されます (ただし、事前にメッセージが表示され、続行するかどうかが確認されます)。Windchill RV&S このようにして作成されたバリアント サブプロジェクトは、その後ユーザーが伝播をキャンセルした場合もターゲットの階層に残ります。このことは、Windchill RV&S の制限として把握しておく必要があります。ターゲット プロジェクト ツリーに対する他のすべての変更は、実行される差分変更のセットをユーザーが確認し、伝播を続行することに同意した場合にのみコミットされます。