Description - Mks.com

Once the dependencies are calculated, and you have performed the required merges, the
operation completes and Source Integrity presents all the files required for the new feature or
content in your sandbox.
When Should I Use Resync CP?
You should use the Resync CP command when the Apply CP operation has failed because there
were conflicts to be resolved through merging or if there are additional changes that need to be
made in order to incorporate the change packages into the target project. Resync CP is most
useful for developing software features and for applying bug fixes during the software development
process.
Note:
When working in your sandbox, you can also use the Resynchronize By CP command.
When you select a member and use Resynchronize By CP, Source Integrity automatically
searches the change package associated with the member and resynchronizes the selected
member and all other member files contained in that change package. For more information,
see si resync.
If the issues you are looking at have numerous associated change packages, you can also use a
single change package--a resolution change package--that contains all the associated change
packages, to resolve it. The Resync CP command includes a process for creating resolution
change packages that can be used for this purpose.
Note:
If you attempt to perform a Resync CP command on a member that was previously dropped
from a project, Source Integrity instructs you to manually re-add the member.
Resolution Change Packages
There are instances when the Apply CP command does not work on a set of change packages
because merging is required. When this happens, the Resync CP command must be used to
automate the required merging. Once the Resync CP operation is completed, the modified files
that result from those merges are transferred to your sandbox. To apply the changes, you must
then check in those modified files.
For a development team using the change package methodology, the check in of the modified files
requires an associated issue and change package. Once the issue has been created, the files can
then be checked into the associated change package and the development path updated with the
merged files.
If other developers want to apply the same set of change packages, how can they be certain that
the changes made relate only to the target feature and that no other changes have been checked
in? To be absolutely certain, they would have to repeat the original Resync CP operation--a
208 of 457