Re: now with more agressive elision (was: [PATCH] svn mergeinfo --elide)

On Sat, Sep 10, 2011 at 1:07 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Sat, Sep 10, 2011 at 12:45:50PM -0400, Paul Burba wrote:
>> ### This leaves us with a situation where r4 hasn't been merged
>> ### to the branch:
>>
>>   trunk_at_1167503>svn st
>>    M      branch
>>    M      branch\B
>>   M       branch\D\gamma
>>
>>   trunk_at_1167503>svn pl -vR
>>   Properties on 'branch':
>>     svn:mergeinfo
>>       /A:2-4
>>   Properties on 'branch\B':
>>     svn:mergeinfo
>>       /A/B:2-3
>
>> But your patch would elide[2] the mergeinfo on ^/branch/B and make it
>> appear r4 was fully merged to ^/branch, which is clearly not the case.
>
> Quite right, it would only leave /A:2-4 on the 'branch' directory.
> Thanks.
>
>> [1] Of course a path with explicit mergeinfo never inherits mergeinfo,
>> what I mean here is simply the mergeinfo it would inherit *if* it had
>> no explicit mergeinfo.
>
> So non-inheritable ranges only apply to nodes which do not have their
> own svn:mergeinfo.

No, rather, "non-inheritable ranges only apply to nodes which *DO*
have their own svn:mergeinfo."

Say a path src/branches/b1 has the mergeinfo:

'/src/trunk:556-1001:1200*

r1200 applies only to src/branches/b1, the path on which it is
explicitly set. All of b1's children inherit only r556-1001.

I'm pretty sure you already know this, it's just that we keep using
different words to describe the same thing ;-)

> And any subtree mergeinfo overrides the mergeinfo
> of its ancestors.

Yes, that is all I was trying to say. If a path has explicit
mergeinfo that mergeinfo is a complete description of what has been
merged to that path, we don't care about any of the path's parents.

>Correct?

> In which ways do you think automatic elision needs to be improved?

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.

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.

Today only 'A' is supported when 'B' and 'C' are empty sets.

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

Paul
Received on 2011-09-10 20:09:12 CEST