On Sat, Sep 10, 2011 at 02:08:38PM -0400, Paul Burba wrote: > Given: > > A path P and some path-wise child of P called C: > Assume both P and C have explicit mergeinfo. > Assume there is no intermediate patch between P and C with explicit > mergeinfo. > Assume P and C are at the same revision as are any intermediate > paths between them. >
Ah, right. I didn't think at all about mixed-revisions... > Question: > > Can the mergeinfo on C elide to P? > > Looking at the intersection of the P and C's mergeinfo we have: > > A) Common mergeinfo (that differs only by the path-wise difference > between P and C) - This can elide. > > B) Mergeinfo exclusive to P - If *all* of this describes merges that > are inoperative on C, then this can elide. > > C) Mergeinfo exclusive to C - If all of this describes merges that are > operative only on C and/or on subtrees which are not part of P, then > this can elide. > > If elision occurs in *all* three cases then the mergeinfo on C can elide to P. Nice. We should try to implement that. > > Do you think there is value in adding just 'svn mergeinfo --elide' > > and keep using the present elision code? > > Yes, I think the basic idea is sound: Some way to trigger the elision > code outside of a merge proper. Admittedly today it has rather > limited usefulness, but only because elision itself is so "dumb". > Once elision gets smarter it will be more useful. But there's no > reason no to add it now. Ok, I'll add the --elide option so. Thanks Paul!
