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 _______________________________________________ Svnmerge mailing list [email protected] http://www.orcaware.com/mailman/listinfo/svnmerge
