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

[Auke Jilderda]

On Wednesday 14 February 2007 09:56, Raman Gupta wrote:
>
> 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.

I mean the way as in the use case  as I described in a recent post [1]: When 
you copy a change set from branch A to B and then from B to C, the latter 
copy will generate a conflict on the property used for merge tracking. This 
is because svnmerge.py uses the same key for that versioned property on every 
branch.

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

You misunderstood: the problem is that the versioned property key is the same 
so the svn client raises a conflict.

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

Yes, that would solve the issue.

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

Um, how do you define "transitive merging"?

To be able to use svnmerge.py, we need to be able to merge from A to B, from B 
to C, and so on.  Transitive merge information would be nice to have but not 
essential.

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

Ah ok, I got slightly lost in the technical details earlier in this thread: to 
the best of my understanding, your patch would avoid the conflict on the 
versioned property but flushes transitive merge information.  But does this 
mean that the value it is set to is still correct?  (That is, need not be 
transitive but at least define exactly what revisions from what branch have 
been merged on this branch.)

Also, has the patch been accepted into svnmerge.py or is there a place where I 
can get svnmerge.py with your patch to take this out for a spin?


Auke

 1. http://www.orcaware.com/pipermail/svnmerge/2006-December/000790.html