My development group follows the unstable trunk, stable branches pattern in Subversion. Every month, a stable release branch is created from the trunk. Occasionally, changes need to be merged from these release branches into subsequent release branches and eventually, to the trunk.
The problem is that, over the past few months, the merges were done incorrectly across all of these branches. Many revisions were skipped due to developers misunderstanding what revisions they needed to merge.
An example incorrect merge history would look like this:
------------------------------------------------------------------------
r57 | Bob | 2008-11-27 04:02:46 -0600 (Thu, 27 Nov 2008) | 1 line
action:merge; origin:branches/1; target:branches/2; range:28-55
------------------------------------------------------------------------
r28 | Alice | 2008-11-25 10:14:00 -0600 (Tue, 25 Nov 2008) | 1 line
action:merge; origin:branches/1; target:branches/2; range:10-25
Here, Bob should have started his merge from r25, where Alice's merge ended, instead of r28.
So now I have 6 branches that have been merged incorrectly since early October in this way. This causes test failures and many regressions in the trunk. So now, I want to go back and merge all of the missed changes.
Is there an easy and correct way to do this? My current plan is to go back to the beginning and start merging in each gap. So in the example, I would merge revisions 25-28 from branch 1 to branch 2. But I expect many conflicts and I'm hoping there's a better way.
There really is no quick and easy fix for this. Forcing developers to maintain multiple concurrent branches in Subversion is error-prone and time-consuming. In this case, many of the developers' checkin comments are inaccurate anyways. So there really is no way to go back and retrace their steps. Instead, we will fully test the most recent branch and close the rest.