ユーザーヘルプ > 変更パッケージ内の作業単位のグループ化 > CP の適用と CP の再同期の高度な概念 > 変更の伝播に関連する問題
  
変更の伝播に関連する問題
変更の伝播に関連する問題の多くは、メンバーの移動および名前変更と、サブプロジェクトの移動に関係しています。これらの問題は、次の 2 つのカテゴリに大きく分けられます。
ソースのメンバーまたはサブプロジェクトが移動または名前変更されている場合に、対応するメンバーまたはサブプロジェクトをターゲットで見つける
複数の移動操作が行われている場合に、最善の順序でエントリを処理する (ネストされたサブプロジェクトの移動操作では特に重要)
ソースのメンバーまたはプロジェクトが移動または名前変更されている場合に、対応するメンバーまたはサブプロジェクトをターゲットで見つける
特定の変更パッケージ エントリのターゲット プロジェクトを見つけるために Windchill RV&S が使用するプロセスの概要を以下に示します。
1. その変更パッケージ エントリを所有するソース プロジェクトへのパスに基づいて、ターゲット プロジェクト (そのプロジェクトの別のバリアント) が既にターゲットの階層に存在するかどうかを確認します。Windchill RV&S ターゲット プロジェクトが存在する場合は、それをターゲットとして使用します。
2. ターゲット プロジェクトが存在しない場合は、ソース プロジェクトがまだ存在している (登録されている) かどうか (ソース プロジェクトが移動されたり削除されたりしていないかどうか) を確認します。ソース プロジェクトが存在する場合は、対応するバリアント サブプロジェクトをターゲットの階層に作成します。
3. ソース プロジェクトが存在しない場合は、移動された可能性があるため、変更パッケージ エントリにエンコードされている構成パスを使用して、ソース プロジェクトの移動後の場所を探します。ソース プロジェクトが見つかった場合は、対応するプロジェクトをターゲット プロジェクト ツリーで見つけるか、作成します。Windchill RV&S
4. 前の試みが失敗したら、その後は施行されません。Windchill RV&S では、変更を伝播するターゲット プロジェクトを検索できません。手動で伝播を実行する必要があります。
* 
ここでは、このプロセスの大まかな概念を説明することのみを目的としているため、Windchill RV&S によって使用されるロジックが大幅に単純化されており、このマニュアルの範囲を超える数多くの詳細が省略されています。
5. ターゲット プロジェクトが見つかったら、今度はそのターゲット プロジェクト内で、変更を伝播する必要があるメンバーまたはサブプロジェクトを探します。Windchill RV&S
移動と名前変更以外の操作の場合は、ソース プロジェクト ツリー内のメンバー (またはサブプロジェクト) と同じ名前のメンバー (またはサブプロジェクト) をターゲット プロジェクト ツリーで探します (そのメンバーまたはプロジェクトのバッキング アーカイブまたはプロジェクトが同じであることを確認します)。Windchill RV&S 対応するターゲットが見つかった場合は、それを更新します。Windchill RV&S それ以外の場合は、ターゲット プロジェクトに (同じバッキング アーカイブまたはプロジェクトをポイントする) メンバー (またはサブプロジェクト) を追加します。Windchill RV&S
移動操作と名前変更操作の場合は、Windchill RV&S Server の基本的なプロセスは他の操作と変わりませんが、移動操作や名前変更操作の "前" と "後" の両方の名前が Windchill RV&S Server にわかっているため、より高度な検索が行われます。
複数の移動操作が行われている場合に、最善の順序でエントリを処理する
先にも述べたように、Windchill RV&S は通常、バケット内のエントリを時系列順に調べます。したがって、前のエントリは後のエントリより先に処理されます。
* 
Windchill RV&S は、変更を 1 つずつ順番に伝播するのではなく、変更を順番に調べて、そのバケットの最終結果を 1 つ生成します。
最終結果は、所属する親プロジェクトごとにグループ化され、対応する操作が、各親プロジェクトに対して 1 つの一括操作として Windchill RV&S Server 上で (実行可能なときに) 実行されます
操作が複数のプロジェクト (またはサブプロジェクト) にまたがって伝播される場合は、各プロジェクトに対応する一括操作が、Windchill RV&S Server で最適な順序で処理されます。プロジェクト (またはサブプロジェクト) が階層内にある場合には親プロジェクトが子サブプロジェクトよりも先に処理されるように、構成パスの情報を使用して処理順序が決定されます。このような順序で処理すると、複雑なサブプロジェクトのリファクタリングのシナリオ (複数のネストされたサブプロジェクトの移動など) を伝播する場合に良い結果が得られることがわかっています。