5

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?

user449236
  • 513
  • 1
  • 4
  • 6

1 Answers1

6

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.

Mike Miller
  • 2,149
  • 1
  • 18
  • 23
  • In this scenario, I will not be doing svn merge --reintegrate ever, is this correct? – user449236 Mar 29 '11 at 10:48
  • You don't have to if you don't want to. svn:mergeinfo will still get filled in during normal merges. --reintegrate is for doing the whole branch in one shot. Merge-tracking should still know when items have already been merged and prevent conflicts from double-merging the same item. – Mike Miller Mar 29 '11 at 13:59
  • 1
    keep in mind that you should only use reintegrate merge when merging branches that will no longer be developed on, such as completed feature branches. use the "merge a range of revisions" option when porting fixes from patches to the trunk. – Steve Goykovich Mar 30 '11 at 19:59