A note on SVN branching and merging

Background

The company which I work for recently adopted SCRUM at the organizational level which had an impact on the SVN branching and merge policies. It was decided that every team involved in the development of some feature for the product will have a development branch (also called as sprint branch or feature branch) created for the duration of the sprint and has to be merged back into the trunk at the end of the sprint. But since multiple sprint teams are involved in the overall development of the product, they will also have to branch out from the trunk and merge their branches back into trunk at the end of their sprint. Due to such a situation, the sprint teams will be committing the code into the trunk at different times. This would warrant a code rebase to the teams which are still working on sprint; whenever some sprint team finishes their sprint and merges code into the trunk. Following diagram will illustrate the entire process of branching, code rebase and merge for a sprint team:

A typical SVN merge rebase scenario in SCRUM

This leads to a scenario where there are different SCRUM teams working on different features of the product and each team having its own branch for their sprint (referred to as sprint branch) branched off from a release branch (or trunk) and merged back after the feature development is completed.

SVN commands to use for rebase and merge

To rebase the code from other sprint branches, we start with our sprint branch working copy and run the following command:

svn merge –-revision N:M .

where; N:M is the revision range to be merged into the sprint branch working copy.

To properly merge our branch back to trunk, we start with a trunk working copy and run either one of the following command:

Option 1: svn merge url://trunk@100 url://feature-branch .

Option 2: svn merge --reintegrate url://feature-branch .

The new reintegrate option is a shorthanded version of the 2-URL merge. It calculates the url://trunk@100 part and then executes the EXACT SAME merge API that the 2-URL merge does.

Mergeinfo Problems

Note that svn merge command used during rebase creates a mergeinfo property on the folders that are newly added on to the trunk, but which do not exist in your sprint/feature branch. You have to get rid of mergeinfo property from the subfolders before you do the merge to the trunk.

If you do not do so, when merging sprint branch to trunk using option 1 from above, svn will complain you with following message:

Working copy . not on the path.

and using option2 from above; svn will complain you with the following message.

svn: Cannot reintegrate from 'url://feature-branch' yet: Some revisions have been merged under it that have not been merged into the reintegration target; merge them first, then retry.

Most of the problems with reintegrate stem from this check for subtree mergeinfo. You can refer to a superb article on Subversion merge reintegrate by Mark Phippard (Director Subversion Engineering at CollabNet). If you want to deep dive into the internals of mergeinfo, you can refer to CollabNet article at http://www.collab.net/community/subversion/articles/merge-info.  

If you run into such problems you can try one of the following things:

1. You can manually remove the subtree/subfolder mergeinfo by running the following command:

svn propdel -r svn:mergeinfo FOO

-r option will recursively delete mergeinfo property from all the subtrees.

2. Other option is to use old 2 URL merge syntax as shown above.