A cherry pick is a merge commit where a single or select commits are merged. This section provides information and instructions about cherry-picking commits in Subversion (SVN). It contains the following topics:
- Cherry Pick Merging
- Hot Fix Pattern
- Replay Branch Commits Pattern
Cherry Pick Merging
The svn:mergeinfo property contains the list of paths and commits that have already been merged into the current branch. This is useful if you merge repeatedly into the same branch because SVN will notice and skip over the commits that have already been merged in.
Gives a list of all the svn properties defined in the current directory (.)
svn propget svn:mergeinfo
Gets the contents of the mergeinfo property.
Hot Fix Pattern
There are two branches: stable and development.
The current milestone branch of the Parallel Development Team's
The next milestone branch that is used by the Services team to work on.
If a problem is found in stable that needs to be solved immediately, the commit is made into the stable branch and then cherry-picked later into the development branch.
Check Out for the Target Branch
The existing commit is going to be applied in the following location:
Determine the Revision Number of the Target Commits
You can find the revision number of the target commits as follows:
In this case we want to cherry-pick commit 123456 from CM to NM.
Cherry-Pick the Commit
To cherry-pick the commit, do the following:
Check the Changes
To check that you got the expected changes, do the following:
If everything checks out, you will be ready to commit. If there are merge conflicts, you must resolve them before you commit.
Commit the Merged Files
Once there are no merge conflicts you can commit the merged files. You should use the same JIRA ticket number for the original fix, but also include the revision you picked in the ticket and in the comment as in the following example:
These instructions assume you initiate the cherry pick at the top level directory. Other options can be found in the svn program help for the merge by issuing the following command:
If people commit before you, do an svn update to get their changes before you commit. Since this may affect the clarity of your commit, you'll need to decide whether starting over makes more sense.
Replay Branch Commits Pattern
Sometimes a Sync Merge is required, but it can be impractical due to divergence in paths unrelated to the feature branch work. For example, there might be many tree conflicts that are difficult to resolve. In this scenario, it makes more sense to create a new aggregate branch at the current PDT Trunk and apply the feature branch work on top of the new aggregates. To do this, use the following steps:
- Determine the range of commits for each branch that needs to be reapplied.
- Create a new set of aggregate branches onto which the commits will be replayed.
- Replay the commits 1:1. However, you can skip reverted commits.
- Run the rebased code to verify it works.
- Archive the original branch and replace it with a copy of the replayed branch.
Determine Commits For Each Aggregate Branch to Replay
Use the svn-merge-tools: show-branch.sh script to get a list of the commits to replay.