[Svnmerge] Two-level branching

[Jack Repenning]

On Jun 15, 2007, at 3:25 AM, Oefelein, Martina wrote:

> Suggestions? Has anybody experience with such a two-level branch  
> merging scenario?

I've used two-level (and deeper) branching schemes extensively, but  
your challenges here have considerably more to do with the sort of  
changes you plan, than merely with your branch topology.

A major compiler upgrade tends to have extremely pervasive impact, as  
you've noticed. And the set of lines that need to be changed doesn't  
really have any semantic pattern, you can't organize it based on your  
primary features or anything else that makes sense to your design or  
team assignments.  So, as you suggest, there's every reason to expect  
merging into or out of your branch B2 to have conflicts ... silly,  
annoying conflicts like adding a parameter or casting a variable, but  
conflicts none the less, that have to be reviewed by a human because  
the poor computer can't guess what to do.  And in so great a flurry  
of silly, annoying conflicts, there's a very high probability there  
will be real, substantive changes that get missed or botched or lost  
or mangled.  Whoa!  So, all of a sudden, this annoying clerical  
operation becomes threatening to the integrity of your product.

For this reason (the very high risk of silly annoyances cascading  
into substantive problems), I would strongly advise you to change  
your primary plan.  Rather than trying to do this compiler upgrade  
off on the side while allowing other work to continue, make the  
compiler upgrade an all-hands, nothing else matters task for a  
while.  Get the deprecations and library upgrades and so on licked,  
on the main branch, with all parties involved, in the shortest time  
possible, and then return to your regular process.

That's what you should do.  But this is reality: there are often  
reasons why you can't do what you should.  If you can't do the above,  
then you should consider the questions you did ask in the light of  
the same fundamental risk: your parallel development will create a  
lot of merging, and will muddle together merges that are strictly  
superficial compatibility tweaks with those of real substance.

The most important property of your branch plan, then, is "how clear  
will it be, to the human resolving the merges, what's going on in a  
given conflict?"  That clarity comes from familiarity: you're going  
to depend a lot on someone remembering the hoops they had to jump  
during the last merge and spotting another case of the same thing, or  
someone messing with the base code they hoop-jumped out of  
recognizability last time around.

I'm not certain, but it sounds as if you imagine branches B1 and B2  
will both be owned by "the people doing all this porting" (which, I  
suspect, will be you?), whereas the trunk will be owned by "a million  
other people."  In that case, your best chance to build in  
familiarity is between B1 and B2, the branches owned by the same  
people.  And conversely, the worst mistake you could make,  
familiarity-wise, would be to obligate yourself constantly to explain  
the difference between B1 and B2 to all those millions of other  
people.  So, make B1 the only recipient of merges from trunk; that  
way, whenever you have to ask for advice from the millions who are  
mostly ignoring this effort, they have a fighting chance of  
remembering what they formerly knew about B1.  Meanwhile, merge out  
from B1 to B2 is wholly under the control of "the porting people,"  
who can become very familiar with the quirks of this pair.



-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
aim: jackrepenning
skype: jrepenning