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 _______________________________________________ Svnmerge mailing list [email protected] http://www.orcaware.com/mailman/listinfo/svnmerge
