ユーザーヘルプ > 変更パッケージ内の作業単位のグループ化 > 変更パッケージの再同期の概要 > バイナリの競合の解決
  
バイナリの競合の解決
1 つのバイナリ ファイルの 2 つのリビジョン間で競合が発生すると、Windchill RV&S はそのメンバーのサンドボックス ワーク ファイルをマージ先のリビジョンで置き換え、それを競合としてマークします。宛先のリビジョンは伝播変更パッケージに "Deferred Check In" エントリ (ワーク ファイルの遅延中のチェックインを表します) として表示されます。たとえば、リビジョン 1.1 および 1.1.1.1 が両方とも、メンバーリビジョン 1.2 とのマージを必要としている変更パッケージ内のバイナリ メンバーの更新リビジョンエントリである場合、リビジョン 1.1.1.1 の内容がメンバーリビジョン 1.2 のサンドボックス ワーク ファイルに使用されます。リビジョン 1.2 は、伝播変更パッケージに "Deferred Check In" エントリとして表示されます。バイナリ ファイルの内容の比較は実行されません。変更パッケージがサブミットされると (またはメンバーがチェックインされると)、メンバーリビジョンは 1.3 になります。
次のいずれかの方法で競合を解決できます。
ターゲットリビジョンを使用する
伝播変更パッケージ内の変更をサブミットし、そのバイナリ メンバーのマージ先のリビジョンをチェックインします (またはマージ先のリビジョンの遅延中のチェックインを手動でサブミットします)。
手動でバイナリ マージを実行する
Windchill RV&S 以外のサードパーティ ツールを使用して、影響を受けるメンバーでバイナリ結合を実行します。その後、変更を伝播変更パッケージでサブミットします (またはマージ先のリビジョンの遅延中のチェックインを手動でサブミットします)。
元のリビジョンを使用する
宛先のリビジョンではなく元のリビジョンを使用して、競合に対応する "Deferred Check In" エントリを破棄します。競合を解決するには、必要なリビジョンを指定するDeferred Update Revision 操作を使用して必要なリビジョンを指定します。