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.
If the developers were checking in their changes in the branches along the way, couldn’t you create a new branch prior to the merge, merge the changes correctly, then merge their new code in? Maybe I’m missing something.
I’m not familiar with the various Subversion patterns, but my company follows a process where our trunk is always stable, and developers cannot change it (can only change the branches). We’ve never had merge issues as a result, and we have over 10,000 revisions and 100 branches in SVN. I’m only bringing this up because it sounds like you have a major flaw in your process/pattern if there are MULTIPLE developers having merge issues.