How to properly update a feature branch from trunk?

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.

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?

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:

FB_0=trunk_0

FB_1=FB_0 + change_a

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

FB_3 = FB_2 + change_b

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

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

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

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.

After research:

After many brainstorming sessions at visionmap, F2F discussions including Artyom, opening an SVN book case, etc - it looks like this is not possible to do. A feature branch is totally not like working copy. The only working way to update it is recreate a new branch, as described above.

We're an small company, so I don't known if our solution will apply to your situation. What we do is a rev-by-rev merging from trunk to the stable branch. We can do it in 2 different ways: - Really needed fix, we merge just after committing to trunk - Dangerous fix/change. We wait some days until the change is proofed in trunk and then we merge

With this continuous merging we avoid tons of conflicts.

My 2 cents.

上一篇: 在LINQ中查询数组的位置

下一篇: 如何从trunk中正确更新一个功能分支？