[Svnmerge] Pending patch to handle svnmerge-integrated property conflicts

[Raman Gupta]

Giovanni Bajo wrote:
> On 7/5/2007 1:51 AM, Raman Gupta wrote:
>> http://tinyurl.com/39h6x5
> 
> I think you raise fairly good points in your latest mail. I've never 
> used transitive merge infos, and svnmerge isn't even supposed to support 
> such merges. Also, I notice that this is the behaviour with -b, which is 
> even supposed to be the default, was not for performance issues.

For the benefit of future discussion, lets not conflate "transitive"
merging with "graph" merging. I think you actually mean the same thing
I mean above when you say "transitive" but just to clarify so everyone
is on the same page... Transitive merging is:

A <--> B <--> C <--> ...

Graph merging is:

A <--> B <--> C <--> A

My patch *adds* support for transitive merging to svnmerge.py (which
previously resulted in property conflicts). Graph merging is just as
unsupported as it was before, but perhaps now a little more explicitly
so since merge-props won't be copied around willy-nilly :-)

> It's also counter-intuitive that the quote to handle merge-prop 
> conflicts is guarded by -b. I don't see a direct connection: it's just 
> that, with bidirectional merge, it's more common to see conflicts.

I agree.

> On the ground of this, I'll approve your patch (as amended by Daniel 
> Rall with the testcase).

Cool.

> People interested in true graph merge support are encourage to provide a 
> more complete meta-merge implementation (manual merge of prop-merge 
> conflicts).

Absolutely. Perhaps until such an implementation is available,
svnmerge.py should be modified to fail gracefully if a graph merge is
attempted? Currently I believe graph merges will most likely result in
conflicts due to reflected revisions via intermediate branches.

Cheers,
Raman Gupta