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!
Received on 2011-09-10 22:06:01 CEST