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 Windchill RV&S 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.
Advantages of Using a Propagation Change Package
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.
Example of Using a Propagation Change Package
The abcBusiness company has two development teams:
• a Product Team that develops new features and software for the main release cycle
• 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 bug is reported by a customer.
• 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.
• An MDT developer is assigned to fix the problem.
• The MDT developer creates a change package.
• The MDT developer makes the necessary changes and tests the code.
• 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 Windchill RV&S 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.
