• This command requires a Sandbox that contains the project revision you want to merge into (parent project).

• Always start with the parent revision and merge into it

• If a project is selected (instead of a sandbox) you are prompted to select the sandbox.

• If you have previously performed a merge from one branch into another, when repeating the operation the command only picks up changes from change packages that were closed after the last merge (only new changes are merged).

• As a best practice, when making changes on multiple development paths, use a separate change package for each development path (ensure no change package contains entries from two or more development paths).

• For large merge operations, a significant number of smaller manual merge tasks may be required to resolve merge conflicts. For documenting such manual merge operations, you can use manual merge lines. For more information on manual merge lines, see Working with Manual Merge Lines.

• As a best practice, the development paths being merged should be structurally the same. Any structural changes performed to a target of the development path merge operation after the source branch was created (such as configuring a subproject) can potentially cause problems during the merge.

• If the project structure contains the same project twice in the same level (for example, a subproject in the mainline and a subproject configured as a variant) then the merge is not recorded and the merge line does not display in the project history.

• When the propagation change package is submitted, Integrity Lifecycle Manager checkpoints the destination project. The destination project is locked during the duration of the checkpoint.

• If you are running a separate server for configuration management from the server used for workflows and documents, ensure the server clocks are synchronized.