Understanding Change Packages in View Compare/Merge

Change packages improve StarTeam’s ability to manage and track updates. A change package is an object that contains a set of changes applied to a target view. Change packages are created using the View Compare/Merge.

When you first start a View Compare/Merge session it acts as a staging area where changes are defined, reviewed, and tested. A View Compare/Merge session is visible in the target as a change package when the session is saved or committed. When the View Compare/Merge session is committed, its changes are atomically applied to the target view, and a change package object records the changes. Subsequently, a change package can be replayed, causing the same changes to be applied to another view.

Change packages represent sets of logically-related software artifact changes. A change package typically contains the changes needed to fix a bug or implement an enhancement, but it can include any set of updates defined by a user as a single logical change. A typical change package will contain mostly new file revisions, but it can also include related non-file changes such as marking a change request as fixed or updating a task as complete. A change package can include updates to any number of items of any type supported by StarTeam .

When showing changes for a selected item, the Cross-Platform Client shows both legacy and enhanced process links as well as links to relevant change packages. Links to change packages are more granular than links to process tasks. For example, links are created for update items other than files and folders, and links are created for updates not currently covered by process links such as deletes. The changes defined by a change package are applied as an atomic transaction which means that all of the changes are applied, or none of them are applied.

A change package also includes properties that represent metadata, such as a name, who created the change package, its purpose (description), who last modified the change package and when, and so forth. When a change package is committed, it is stored with the transaction ID with which its changes were applied. The transaction ID allows audit records and command traces associated with the change package to be identified.

Because change packages are persistent, you can browse change packages and their details. You can view all change packages applied to a view in chronological order, and for a given change package you can see both item- and non-item (metadata) change details. You can also query the change history of an item to determine which change packages, if any, were the source of any updates.