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

[Auke Jilderda]

Raman,

have you pursued the implementation of supporting merge tracking across more 
than two branches (optionally with even providing transitive merge tracking 
information)?

To support merge tracking across more than two branches, I (as layman w.r.t. 
the implementation) see four possible solutions: (a) prepend the path to the 
key of the versioned property, (b) not propagate the versioned property, (c) 
enable the init sub command to manually specify the name of the property 
used, or (d) automatically merge the versioned property's value.

Option (d) seems the most elegant (and is what Daniel is doing on Subversion's 
merge-tracking branch) but would require that the Subversion command-line 
client (as driven by svnmerge.py) to allow not merging a 
directory's "svnmerge-integrated" property while merging other properties and 
the contents of that directory.  The command-line client doesn't currently 
allow this; it might be doable at the Subversion C API level but Daniel tells 
me that that would probably require quite a bit of work.  Option (a) isn't 
backwards compatible but would be the easiest to hack in. Option (c) would 
require the user to name the property for every subsequent invocation of 
svnmerge.py which would be a nuisance to put it mildly. Option (b) isn't 
feasible; it has the same problem as described for option (d).

Would it be feasible and interesting to have a modified svnmerge.py that 
implements option (a) for those who don't mind not being backwards compatible 
but need to be able to merge across multiple branches?  It seems the quickest 
solution to bridge the time until 1.5 arrives even though it may not be 
useful to some of the current users of svnmerge.py that need to maintain 
their merge tracking information already built up.


Auke

On Wednesday 13 December 2006 13:44, Auke Jilderda wrote:
> 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