Using the Apply CP Backfill List
If the change packages you are applying are dependent on other change packages, the Apply CP command presents you with a backfill list that includes all of the required change packages. The following examples illustrate how the backfill list works in the Apply CP command.
In the Apply CP operation, you must accept the entire backfill list or the operation fails. If you do not want to accept the entire backfill list, you must instead perform a Resync CP operation. The Resync CP command allows you to merge around unwanted revisions in your Sandbox.
* 
The backfill list is not used when applying subproject operations. You must explicitly specify all change packages containing subproject operations that you want to apply or select Implicitly for the Propagate Subproject option.
Using the Backfill List to Include Required Previous Revisions
In this example, the main project, f:/Aurora_Project/project.pj includes two bug fixes. Item 21 addresses the first bug fix and is associated with the file main.c (revision 1.2) through change package (CP) 21.1. Item 22 addresses the second bug fix and is associated with the file main.c (revision 1.3) through CP 22:1.
The buildmaster wants to pick up the changes that address the second bug fix and apply these to a variant project, Aurora_Variant_1_0. In the variant project, main.c is at revision 1.1.
Before applying a change package that requires backfilling
To pick up the bug fix for the variant project, the buildmaster uses the si applycp command to apply CP 22:1. By default, the backfill option is set to Entire Change Packages (--backfill=cp). The buildmaster enters the command:
si applycp -P f:/Aurora_Project/project.pj --devPath Aurora_Variant_1_0 22:1
The command runs as follows:
Applying change packages...
22:1
The following warnings have occurred:
-------------------
The change package(s)
21:1 -- main.c(1.2)
are required in order to apply this list of change packages.
They will be automatically added to the list, since the backfill
option is set to Entire Change Package(cp).
--------------------
*** The following set of operations will be performed:
Project: f:/Aurora_Project/project.pj[Aurora_Variant_1_0]
Member main.c: update member revision to Revision 1.3
Are you sure you wish to proceed? [yn](n): y
If you choose to proceed, you receive a notification listing the updates that have been processed, and any updates that were not processed.
Apply CP updates the revision for main.c from 1.1 to 1.3 in the variant project. Revision 1.2 is automatically added to the variant project because it was accepted as part of the backfill list (CP 21:1).
After applying a change package that requires backfilling
Using the Backfill List to Include a New File
This example illustrates how Apply CP handles a more complex change package—one that contains code modifications that are dependent on a new file. In this example, main.c is revised to call a value defined in a new file, main.h.
The developer working on the code has checked in all these changes and associated both files with CP 22:1. Development work then continues to include a further revision to main.c which is checked in at revision 1.3 and associated with CP 23:1. The main project therefore contains main.c at revision 1.3 and main.h at revision 1.1.
Before applying a change package that contains an associated file
The buildmaster now wants to incorporate the changes into the variant project. The buildmaster therefore uses the Apply CP command to apply CP 23:1 to Aurora_Variant_1_0. This updates main.c to revision 1.3 and adds main.h revision 1.1.
After applying a change package that contains an associated file
Using the Backfill List to Apply Back Revisions Only
The default backfill option for Apply CP is to propagate all entries required by the specified change package, including all entries in any change packages in the backfill list. However, there is a special case where you might want to backfill by Back Revisions Only. This option only updates the target environment based on the directly associated revisions. It does not process any change packages that are associated with intermediate revisions.
For example, if you chose the Back Revisions Only option in the previous example (“Using the Backfill List to Include a New File”) main.c would still be updated to 1.3, but main.h would not be propagated since it is an entry in a backfill change package.
This option is useful where you are propagating a file that collects information and therefore tends to be affected by all changes. In this case, you are only interested in the latest revision, not the underlying changes that occurred as a result of all the changes to related files.
Was this helpful?