Net changes are determined by calculating a single operation for each member or subproject that represents the net change for that member or subproject in order to make the target project equivalent to the source project.

For the Apply CP command, the net change needs to correspond to an existing artifact in the repository. For example, for a member, the net change needs to correspond to an existing revision in that member’s archive (unless the net change is to drop that artifact). If it is impossible to resolve the net change into an existing artifact (possibly because a merge is required) the propagation fails and you (the user) must use the Resync CP command to perform the task instead.

The Resync CP command also calculates a single operation for each member or subproject, but unlike Apply CP, Resync CP operates in the context of a sandbox and allows merges to take place in the sandbox which will be checked in to create a new revision in the member’s archive when the propagation change package is submitted. However, there are limits on how complex the merge can be. For example, if generating the single operation for a member requires merging in (or merging out) two or more discontiguous sets of revisions from the member’s archive, the operation fails. It is still possible to propagate the changes in most cases, but the propagation needs to be broken up into smaller parts and performed sequentially.

An important factor in understanding how Integrity Lifecycle Manager determines net changes is that Integrity Lifecycle Manager considers a change as already having been propagated from the source to the target if the member revision in the target is already at (or beyond) the revision that the net change indicates should be propagated. This specifically has implications in two cases: first, when you try to re-propagate a change from the source project tree to the target project tree; and second, when you try to propagate a change that moves a member revision backward along its history. In both cases, Integrity Lifecycle Manager determines that the target already has the required change, so it performs no action. The following is an example:

John, a developer, has member bar.txt at revision 1.6 in the source project hierarchy, but that same member is at revision 1.5 in the target project hierarchy. In the source hierarchy, John creates a new change package 1:1 containing an entry which does an Update Member Revision operation of bar.txt back to revision 1.4. If another user, Mary, tries to propagate this change package to the target using Apply CP (or Resync CP), Integrity Lifecycle Manager does nothing since the target already has the change (since by implication revision 1.5 is built on top of 1.4). If Mary wants to force the member revision back to 1.4 in the target, she must do so manually and cannot rely on Apply CP (or Resync CP) to do it for her.

This behavior of determining which changes the target "already has" is based on revision numbering. Ignoring those changes is fundamental to the command process and has impact on the backfill process as well.

Another important factor in understanding how Integrity Lifecycle Manager determines net changes that needs to be understood is that only changes that actually affect the project’s member and subproject configuration are taken into account when propagating. For example, it is possible to check in new revisions to an archive using a change package and at that time indicate that these new revisions should not update the member revision in the project. When propagating this change package to the target, those entries are ignored by the command since they do not update the member configuration in the source project.

Integrity Lifecycle Manager handles the net changes by internally creating a virtual bucket for each member or subproject that it encounters in the list of change packages to be propagated (including the changes explicitly specified by you (the user) and the ones you specify to pick up in the backfill). Integrity Lifecycle Manager examines all of the change package entries in those change packages one at a time in the order in which they originally occurred, and then adds the entry to the appropriate bucket. The changes are grouped in the following way:

For Integrity Lifecycle Manager to be able to propagate the changes from the source project tree to the target project tree, Integrity Lifecycle Manager must locate (or if necessary add or create) the corresponding target member or subproject for each source member or subproject.

For subprojects, if Integrity Lifecycle Manager determines that a subproject is missing in the target, the corresponding variant subproject will be created in the target immediately during the initial phase of calculating the net changes to be propagated (although you the user are prompted in advance that it needs to do so and asked if it is ok to proceed). Variant subprojects created in this way remain in the target hierarchy even if you later decide to cancel the propagation; a limitation of Integrity Lifecycle Manager that you need to understand. All other changes to the target project tree are only committed if and when you have had a chance to examine the set of net changes to be preformed and you agree to proceed with the propagation.