Resolving Binary Conflicts
When a conflict between two revisions of a binary file is encountered, Windchill RV&S replaces the Sandbox working file for that member with the destination revision and marks it as a conflict. The destination revision displays in the propagation change package as a Deferred Check In entry (representing a deferred checkin of the working file). For example, if revision 1.1 and 1.1.1.1 are both update revision entries of a binary member in a change package that require a merge with member revision 1.2, then the contents of revision 1.1.1.1 are used for the Sandbox working file of member revision 1.2. Revision 1.2 displays as a Deferred Check In entry in the propagation change package. No comparison of binary file content is provided. When the change package is submitted (or member checked in) the member revision is 1.3.
You can resolve the conflict in one of the following ways:
• Use Target Revision
Submit the changes in the propagation change package, thereby checking in the destination revision for the binary member (or manually submit the deferred checkin of the destination revision).
• Perform Manual Binary Merge
Using a third-party tool outside of Windchill RV&S, perform a binary merge on the affected member. Then submit the changes in the propagation change package (or manually submit the deferred checkin of the destination revision).
• Use Original Revision
Discard the Deferred Check In entry corresponding to the conflict, effectively using the original revision instead of the destination revision. To resolve conflict, indicate the desired revision by using a Deferred Update Revision operation that specifies the desired revision.