[Svnmerge] [PATCH] Eliminate spurious svnmerge-integrated property conflicts

[Auke Jilderda]

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
> ...