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

[Raman Gupta]

Auke Jilderda wrote:
> Raman,
> 
> have you pursued the implementation of supporting merge tracking across more 
> than two branches (optionally with even providing transitive merge tracking 
> information)?

Not yet, I've been busy getting my life in order after having moved
back to Canada (my home and native land!) from the USA. What do you
mean exactly by "across more than two branches"?  Svnmerge.py already
supports merge tracking with more than one source via the -S (source)
switch -- just not transitively all that well.

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

Unless I am misunderstanding you, a) is already implemented (sort of,
the path is prepended to the revision value, not the versioned
property key) -- I think this was even part of Archie's original
non-python version.

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

Option d) should really be implemented in addition to the existing
option a) and this could maybe somewhat support transitive merging (at
least better than currently). I don't even think it would be that
complicated to merge the property manually with a little bit of
python-fu i.e. svnmerge.py would use the information on both branches
to explicitly set the property after the merge, whilst ignoring any
merges/conflicts produced by svn's merge algorithm by reverting the
property merge.

Though I'd still like to see a good use case for transitive merging --
I looked through the PDF you sent and I don't think the scenario it
describes is a transitive merging use case -- in fact I think its
pretty vanilla uni-directional merging from older branches to newer
branches. Your summary was this:

>     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 would set up a script that executes svnmerge.py avail on each branch
going forward in time with the prior older branch as the -S (source)
argument, and aggregates the result into some sort of consolidated
report of available revisions to be forward propagated. This would
give you your verification in one command, without any transitive
support in svnmerge.py.

Since svnmerge.py also supports bidirectional merging, you could even
support both forward and backwards propagating fixes simultaneously.

However, transitive support might be useful in your scenario if you
wanted to support the occasional "skipping" of a branch with later
application of that skipped revision. In this case, it would be needed
so that when the skipped revision was applied later, svnmerge.py would
understand that it had already been merged into the next branch
forward in time.

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

If you just want to merge across multiple branches without the
transitive information, svnmerge.py does this already. If my patch is
applied (the one that kicked off this round of discussion about
transitive merging), then it will even do so without conflicts in the
svnmerge-integrated property.

Cheers,
Raman