Applying Changes From a Variant
Working on a variant allows you to create a specific change, test it, and then bring that change back into the main trunk of development. Within reason, this can be done even when the main trunk includes further new development.
For example, a patch created in a variant project is needed in the master project. The file—utility.c—has a head revision of 1.4 in the project. In the variant project, the file utility.c version 1.2 is checked out to revision 1.2.1.1 and the code is revised. The file utility.c is then checked in at 1.2.1.2 and associated with CP 5:1.
Moving a patch from a variant project to a master project
Moving the patch from the variant to the master requires a three-way merge operation using Resync CP. Because the master project contains further new development, updating the head revision of utility.c from 1.4 to 1.2.1.2 would cause the new development work in revisions 1.3 and 1.4 to be lost.
The default Resync CP operation
In this situation, you must use the Merge On Branch option (--mergeOnBranch). This option essentially allows the changes on the branch to be merged into the head revision file. Selecting Merge On Branch allows Integrity Lifecycle Manager to perform a differencing between revision 1.2 and 1.2.1.2 and then merge the result into revision 1.4. Once the Resync CP operation completes, the file must then be checked in to finalize the changes in the project.
Using Resync CP with the Merge On Branch option
Cross-Branch Changes
The Ignore Cross-Branch Entries option allows you to use the most recent revision when there are revisions of the same member on two different branches. This option can be used to accommodate the situation where you need to propagate changes from a variant that has temporary branches which were created in order to bypass locks. In this case, you do not want to include the changes on the branches, which have already been merged into the variant.
