How to properly update a feature branch from trunk

svn

The Subversion SVN book says:

…Another way of thinking about this pattern is that your weekly sync of trunk to branch is analogous to running svn update in a working copy, while the final merge step is analogous to running svn commit from a working copy

I find this approach very unpractical in large developments, for several reasons, mostly related to reintegration step.

  1. From SVN v1.5, merging is done rev-by-rev. Cherry-picking the areas to be merged would cause us to resolve the trunk-branch conflicts twice (one when merging trunk revisions to the FB, and once more when merging back).
  2. Repository size: trunk changes might be significant for a large code base, and copying the differences files (unlike SVN copy) from trunk elsewhere may be a significant overhead.

Instead, we do what we call "re-branching". In this case, when a significant chunk of trunk changes is needed, a new feature branch is opened from current trunk, and the merge is always downward (Feature branches -> trunk -> stable branches). This does not go along SVN book guidelines and developers see it as extra pain.

How do you handle this situation?

Best Answer

From SVN v1.5, merging is done rev-by-rev. Cherry-picking the areas to be merged would cause us to resolve the trunk-branch conflicts twice (one when merging trunk revisions to the FB, and once more when merging back)

Then you are doing something wrong!

Let's see:

trunk    fb
 ---------\
 r1-10    |
 r11-20   |
 r20-30   |

Generally if you want changes done in 11-20, then best practice is to merge 1-20 to fb and get everything there.

Then when fb is done, merge 20-30 and then copy fb to trunk (no merge!).

If you decide to merge only r11:20, ok, at end you will need to merge r1:10 and r20:30 and then copy fb to trunk.

There is no way you merge changes twice!

I assume that you probably do following:

copy trunk->fb
merge 11:20 -> fb.
merge fb-1:30 -> trunk !!!!! WRONG

You can't do this because you would merge 11:20 twice. You should always merge code in one direction only.

Correct way:

copy trunk->fb
merge 1:20 -> fb.
merge 21:30 -> fb (now fb=trunk+feature)
copy fb -> trunk

Edit

So the correct steps are:

  1. Create feature branch (FB) from trunk (copy trunk to feature branch with svn-copy)

    FB_0=trunk_0

  2. Work on FB.

    FB_1=FB_0 + change_a

  3. Merge all upcoming changes from trunk to FB.

    trunk_1=trunk_0 + tr_change_a;
FB_2 = FB_1 + (trunk_1 - trunk_0) == trunk_0 + change_a + tr_change_a

  4. Work on FB

    FB_3 = FB_2 + change_b

  5. Merge all upcoming unmerged changes from trunk to FB.

    trunk_2=trunk_1 + tr_change_n;
FB_4 = FB_3 + (trunk_2 - trunk_1) == trunk_0 + change_a + change_b + tr_change_a + tr_change_b

  6. At this point we have a feature branch that consists of all new features and all changes in trunk. So we just copy the difference between two branches.

    trunk_3 = trunk_2 + (FB_4 - trunk_2) = FB_4 = trunk_0 + change_a + change_b + tr_change_a + tr_change_b

    Now FB deleted as trunk has all changes we need.

    The last step is executed by:

    svn merge /path/to/trunk@LatestRev /path/to/branches/fb@LatestRev .
svn ci

    Or in ordinary language take difference between trunk and branch and put them to trunk making them equivalent.

This pattern is described in http://svnbook.red-bean.com/en/1.4/svn.branchmerge.commonuses.html#svn.branchmerge.commonuses.patterns.feature

Now if this does not work for you, then I don't understand the question.

Edit2: For svn-1.5

When working with svn-1.5 you can merge much simpler:

When you work on feature branch you just merge changes from trunk time to time:

$ svn merge /path/to/trunk
Solve conflicts
$ svn ci

It will line up your FB with all changes in trunk. At the end of FB you run this procedure once more to make sure that everything is up-to date. The you go to trunk and run

$ svn merge --reintegrate /path/to/fb
$ svn ci

In the last one there should be no conflicts if you are working as shown.

Related Topic