Can I keep merging repeatedly from a branch to trunk with Subversion merge tracking?

Question

We released version 1.0 and continue developing 2.0 in trunk. We created branches/1.0 for bug fixes related to the released version.

Plan is:

• 2.0 development continues in trunk/
• trunk/ contains new features that are not to be merged into branches/1.0, so trunk is not merged into branches/1.0 ever
• When bugs are found in the released application, fixes are made into branches/1.0. When a fix set is released into production, branches/1.0 is copied to tags/1.0.x, and branches/1.0 is merged into trunk/
• Idea is that subversion merge tracking should keep track of the changes, so that when we merge 1.0.4 fixes to trunk, 1.0.3 fixes are automatically skipped

Are there any problems with this approach? Will subversion merge tracking keep track of the changes OK? I haven't tried this in practise yet, and most examples do this differently (merging from trunk to branch, which I do not want, as most 2.0 development is not wanted in 1.0 fixes). Does merge-reintegrate fit into this somehow?

Answer 1

Yes, this is exactly what it is designed for. Since the svn:mergeinfo property on trunk is keeping track of which fixes from 1.0 have been merged back, running the merge a second time will not result in it grabbing those revisions again.

Pre-merge-tracking, you would have to keep track of which revisions you merged, and make sure you don't attempt to merge them a second time. Now merging scripts are much cleaner.