User Help > Grouping Units of Work in Change Packages > Apply CP Overview > Using Apply CP in Your Development Environment
Using Apply CP in Your Development Environment
This section provides an example to show how Apply CP can be used in your environment. In this example, the buildmaster brings a feature from the main trunk of project development and applies it to an earlier release.
The abcBusiness software company has released their Aurora software, version 3.0. When the release was completed, the project was checkpointed. The development team is now working on a new set of features for the next release, 4.0. A new feature for this release is a timestamp function. All the changes associated with the timestamp function are recorded in a set of change packages, or set of items, that isolates the feature from other features.
Now abcBusiness receives a request from a customer who has Release 3.0 but also needs the new timestamp feature for its global operations. The code in development for Aurora 4.0 is not stable enough for release and too many resources would be required to accelerate the release schedule. How can abcBusiness provide the timestamp feature without affecting the current release? Because the code for this feature is isolated within a set of change packages, the Apply CP command can be used to propagate the feature to the earlier, stable release.
However, without the functionality of Apply CP, the buildmaster at abcBusiness would have to search the required change package(s) manually and individually review all of the associated files to isolate the changes related to the feature. The buildmaster would then have to add, drop, rename, and move files manually; update file revisions; merge around unwanted revisions; merge in required changes; and merge out any unwanted changes.
Using the functionality of Apply CP, this complicated process becomes largely automated. In PTC RV&S, the Apply CP operation works directly in the project to add, drop, rename, and move files and subprojects, and update file revisions as required to create the desired change. PTC RV&S presents you with a list—the backfill list—including all change packages required to capture the changes. In the Apply CP operation, you must either accept or decline the entire list—you cannot make selections. If you accept the list, the Apply CP command propagates the changes directly to the project. If you decline the list, the Apply CP command cannot complete.
If the Apply CP command fails because merging is required, you can run the Resync CP command. Resync CP works in your Sandbox and allows you to make selections from the backfill list. PTC RV&S then merges around unwanted changes and uses differencing to merge files.
The buildmaster at abcBusiness would:
Create a variant project off the checkpoint for version 3.0. This variant project is isolated from the rest of the development team so that unwanted changes are not added to the main trunk of the development path.
Use Apply CP to apply the change packages to the variant project. The change packages contain all the files that were changed or added to produce the timestamp feature. Apply CP is essentially adding the feature to the variant of Aurora 3.0.
Create an executable of the software.
That executable can then be tested by Quality Assurance and shipped to the customer.
Was this helpful?