The Resync By CP command is primarily a tool for developers. When you want to resynchronize files in your Sandbox, you usually do so by choosing individual files and then using the Resynchronize (si resync) command. However, if the files you are resynchronizing have changes that are linked to other files, the standard resync operation would not include those related files. To resynchronize all related files, you would have to manually search for all the changes associated with the change package on the member you are resynchronizing.

The Resync By CP command automates this process by searching the change package specified on the member revision you are resynchronizing and then bringing the changes from the project to your Sandbox.

While the Resync CP command searches all files related to a selected change package, and all the change packages that may be associated with the related files, the Resync By CP command only processes the change packages associated with the member you are resynchronizing.

To Resync By CP, from a Sandbox view, select one or more members that contain member deltas, and select Member > Resynchronize By Change Package.

Depending on the preferences you have set for the Resynchronize command, when you Resync By CP, the Confirm Overwrite Working File dialog box displays. If you want to retain your changes in the working file, click No (No to All for multiple members). If you want to compare your working file with the revision you are resynchronizing it with, click Differences. To merge and resynchronize the member, click Yes (for multiple members, click Yes to All).

In a Resync By CP operation, the change package list is computed based on the member you are resynchronizing (whereas in a Resync CP operation, you explicitly state the list of change packages).

The functioning of Resync By CP is affected by the settings you choose for the Resync CP command under File > Edit Preferences. This includes the way the backfill list operates. For example, if you specify ask, a backfill list displays.

Developers should use Resync By CP when they want to ensure that they have all dependent changes associated with a member revision, even if these changes are contained in other files. For example, a developer needs to check out (locked) a file and modify it. The developer finds that other revisions have been checked in since the member was resynchronized in the Sandbox. Because the Sandbox is quite large and contains many unrelated changes, the developer does not want to perform a standard resynchronization. The Resync By CP option can be used in this situation.

Consider a case where a developer makes a change to project member main.c, and that change requires an additional file, main.h. A standard resync operation for main.c would not capture main.h.

In the initial stage, Sandboxes pointing to the project include main.c at revision 1.1.

Developer 1 then performs the following tasks:

When Developer 2 uses the Resync By CP command to resync main.c, his Sandbox is updated to show that main.c is at 1.2 and that main.h has also been added to the project as part of CP22:1.