Using a Propagation Change Package with Resync CP

You can use another change package to record all the member changes made by a Resync CP operation. A change package used for this purpose is called a propagation change package.

Even if your administrator has set up change packages to be mandatory, you do not need to specify a propagation change package for a Resync CP operation.

You do not create a propagation change package—you create a normal change package and propagation information is recorded in the change package when you specify it during a Resync CP operation. For the greatest level of control in isolating changes, it is recommended that you start with an empty propagation change package. When the propagation change package contains no previous entries, the only additions will be those that specifically relate to the changes in question.

The propagation change package is populated with all the member and subproject changes performed and the change packages propagated as a result of the resynchronization. You can discard undesirable member changes and add resolved merge conflicts to the propagation change package. You can also add entries to the propagation change package as required using Integrity Lifecycle Manager commands, for example, Check Out, Move, Rename, Update Member Revision, or Create Subproject.

Once all changes are completed, the propagation change package can then be submitted to update the project.

You can also submit the propagation change package without updating member revisions; then the Buildmaster applies the propagation change package at the time the software is built.

Entries in the propagation change package supersede corresponding entries in the resynchronized change packages. Thus, if you perform a merge from a branch and check the result into a propagation change package, the resulting revision supersedes any entries in the listed change packages that might be on branches.

Using a propagation change package ensures that other developers can apply the same set of change packages without duplicating the effort of running the Resync CP command and resolving any errors or merge conflicts.

Propagation change packages are also useful for assisting buildmasters to complete their work. When an Apply CP operation has failed, developers can use the Resync CP command on the same change package, identify the dependencies and required merges, and include all the necessary changes in a single propagation package.

Propagation change packages allow you to incrementally propagate changes between development paths by repeatedly using the Resync CP command to collect project changes, rather than performing one large Resync CP operation that can take a long time.

If you use a propagation change package, any change packages that the applied change package is dependent on that have already been applied to the project through a previous Resync CP operation do not appear in the backfill list. You receive a warning message about the change packages that have already been applied.

It is important to note that while Resync CP can be used to apply a propagation change package, the results may not always be acceptable. For example, if your bug fix is in an existing project member, there would already be an archive for that member in the project. As a result, Resync CP would add the modified member on a branch. This additional branching might not be acceptable in your project.

The abcBusiness company has two development teams:

• a Maintenance Development Team that maintains the released software and addresses bugs that are identified by customers

The Product Team (PT) implements new features and designs on the main development path.

The Maintenance Development Team (MDT) works on a variant development path for Release 2.0 and fixes any problems in the newly-released product. The main goal of this team is to produce bug fixes for Release 2.0a. The work process for the MDT is:

• A change package for the bug is created, in this case it has the container ID 1204. Workflows are enabled, so an item is created and then associated with a created change package.

• The MDT developer checks the modified files back into the variant project, making sure to associate the files with change package 1204:1.

In this case, all the work of the MDT developer is now checked into the variant development path and will be part of release 2.0a. However, the MDT bug fix work needs to be transferred back to the main development path so that it can be incorporated into the next product release. A PT developer needs to pick up the changes that address the bug fix and apply them in a Sandbox. The Resync CP command is the best option for applying the new fix.

The PT developer creates a second change package, 1204:2 for the same item. The second change package includes the summary “Applied fix to main development path”. The PT developer starts the Resync CP command, selects the main development Sandbox, and the first change package—1204:1—in this item. The second change package—1204:2—is used as a propagation change package.

Once all merge conflicts have been resolved, the developer submits the propagation change package and Integrity Lifecycle Manager applies the changes from the referenced change packages.

The bug fix is now addressed in both the main and variant development paths, ensuring that the problem is fixed in the Release 2.0a and the next major product release.