Daniel, Raman, sorry for the slow response but as promised here is a description of the model. It is a multi-tier, linear model of forward propagating fixes:
The basic model is having multiple major release branches, each branched off of its predecessor. Fixes are forward propagated to subsequent releases in chronological order; they are never propagated back in time. Minor release branches are branched off of a major release branch. Fixes on minor releases are propagated to the corresponding major release and from there onwards in the basic approach. Fixes on minor release are not propagated to other minor releases (neither to older or newer minor releases nor to minor releases on other major releases). Customer specifics are actively kept on an absolute minimum but when needed, they reside on a customer specific branch. Customer specific branches are branched off of minor releases. Fixes that are accepted into the main product are propagated to the corresponding minor release, then on to the corresponding major release, and onwards in the basic approach. Fixes that are not accepted into the main product are not propagated to any minor or major release and sometimes are propagated to a corresponding customer specific branch on a later release. Things (should) that never happen: - Propagating 'back in time'. Hence, in reverse chronological order. - A fix is propagated from one minor release to the next on the same major release. - A fix is propagated from one minor release to another on a different major release. Summarising, this is a strictly linear merging model of forward propagating fixes. The transitive merge information is needed to be able to verify that fixes have been propagated to all subsequent releases. I sent you a PDF off-list summarising the same in three pictures. Please don't hesitate if you want more detail or have questions on this model. Auke On 09 December 2006 04:48, Daniel Rall wrote: > > ... > But the above case isn't really graph-like, it's more like a > multi-tier, linear merging model. > > I've asked my co-worker, Auke, to describe our customer use cases in > more depth. I believe they're using it to port changes across very > long-lived (10+ years) active code streams, where (I'm assuming) each > new generation of code stream branches off the previous most recent > stream. When a bug is fixed in one of these streams, it must be > ported back across all other active streams. Performing the porting > by branch by branch, from "most recent" to "oldest" stream, > step-by-step back through time, seems like the best way to go about > this. You can read more about this user's habits here: > > http://subversion.tigris.org/merge-tracking/summit-survey.html#medical-systems > ... _______________________________________________ Svnmerge mailing list [email protected] http://www.orcaware.com/mailman/listinfo/svnmerge
