Cherrypicking (Part 1): Comparing Cherrypicking with Regular Request Merge

Cherrypicking (Part 1): Comparing Cherrypicking with Regular Request Merge

Have you ever been in a situation where a fix applied to one stream was urgently required in another?

This often happens when a bug fixed in a future release is escalated and needs to be included in a patch release. Each patch typically has its own stream so you need to merge the fix from the feature or mainline stream to the patch. To restrict the merged code to the exact bug-fix you need to cherrypick the changes carefully.

Dimensions CM 14.1.x and earlier supports regular request merge but not cherrypicking.


Let’s see the difference in a simple example with two streams...

Assume that we have a Mainline stream with the branch name Main and a Patch stream, branched from the Mainline, with the branch name Patch. Mainline is used to develop future releases and Patch is used to fix versions of the software that have already been released.

Initial scenario  

Initially both streams contain revision Main#1 of the same file. Two independent changes are then made in Mainline:

  • In response to enhancement request ENH1 a new feature is added (the code is marked in green in the illustration) creating revision Main#2.
  • Bug DEF1 is found in Mainline, raised, and fixed (the code is marked in red) creating revision Main#3.

Bug DEF1 is then identified as severe and needs to be merged into the Patch stream. This is the important and tricky part: how do you merge only the bug fix changes and avoid merging other redundant for the Patch changes?


How does merging request DEF1 work in Dimensions CM 14.1.x (and earlier)?

Revision Main#3 is imported into the Patch stream. The problem is that Main#3 also includes changes, introduced by ENH1, that are not required in the patch. You can remove the changes after the import however this is a manual process that is error prone and such approach causes incorrect item pedigree. The pedigree in such case will display a new revision created in the Patch that contains the changes associated with ENH1, while these changes were really removed. If ENH1 is later required to be merged into the Patch the Merge wizard will not report this file at all, because of such item pedigree.

  Regular merge 

 

How does cherrypicking request DEF1 work in Dimensions CM 14.2 (and later)?

Only the changes introduced by DEF1 are applied to the revision in the Patch stream (Main#1), creating a new revision Patch#1.

The revision pedigree has a solid line from the parent revision, Main#1, and a dashed line from the cherrypicked revision Main#3. This indicates that:

  • Only part of revision Main#3 was merged into Patch#1.
  • Revision Main#2 will still be reported as containing differences if ENH1 needs to be merged into the Patch at a late date.

In Dimensions CM 14.2 cherrypicking mode is the default behavior for merging requests and file content cherrypicking occurs automatically unless there are changes in the same lines. You can however switch off cherrypicking if you need to merge everything (potentially including changes introduced in previous revisions of merged file).

  Cherrypicking (aka backporting)

Happy cherrypicking!

 

 

SBM Composer 11.0: Modifying REST Data Before it i...
Getting Started with the Java API Tutorial using E...

Related Posts

Comments 1

 
cs joshi on Tuesday, 25 July 2017 01:17

Recent Tweets