Skip to end of metadata
Go to start of metadata

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

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.

svn:mergeinfo property




svn proplist

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:

Getting Help

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:

  1. Determine the range of commits for each branch that needs to be reapplied.
  2. Create a new set of aggregate branches onto which the commits will be replayed.
  3. Replay the commits 1:1. However, you can skip reverted commits.
  4. Run the rebased code to verify it works.
  5. 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: script to get a list of the commits to replay.


  • No labels


  1. HELP! Tried to follow this and ran into lots of trouble

    here is what I did

    D:\svn\ks\services>svn merge -c 36264
    — Recording mergeinfo for merge of r36264 into '.':
    U .

    D:\svn\ks\services>svn diff
    Index: .
    — . (revision 36250)
    +++ . (working copy)

    Property changes on: .
    Modified: svn:mergeinfo
    Merged /enrollment/ks-api/branches/M6:r36264

    D:\svn\ks\services>svn commit -m "KSENROLL-2864 cherry picked r36264"
    Sending .
    svn: E160042: Commit failed (details follow):
    svn: E160042: File or directory '' is out of date; try updating
    svn: E160024: resource out of date; try updating

  2. This issue has already been resolved but this comment is for others.

    The D:\svn\ks\services directory needs to be a working copy of the latest services branch of ks-api. In this case it was a checkout of ks-api/branches/M6.

    The url specified in the merge command needs to be the source branch. In this case ks-api/branches/M5

    For changes on the impl the changes need to be cherry-picked on a project by project basis from the impl-project/trunk into impl-project/services

    Note that the services impl branch is a dead branch and changes there will only be merged into trunk at the discresion of the PDT on a case by case basis.