[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Partial fix for merge_tests.py 66 failure on mergeinfoless-copies branch

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2007-11-21 20:49:16 CET

Paul Burba wrote:
>> -----Original Message-----
>> From: C. Michael Pilato [mailto:cmpilato@collab.net]
>> Sent: Wednesday, November 21, 2007 12:26 PM
>> To: Paul Burba
>> Cc: dev@subversion.tigris.org; cmpilato@tigris.org
>> Subject: Re: Partial fix for merge_tests.py 66 failure on
>> mergeinfoless-copies branch
>>
>> Paul Burba wrote:
>>>> -----Original Message-----
>>>> From: C. Michael Pilato [mailto:cmpilato@collab.net]
>>>> Sent: Wednesday, November 21, 2007 1:27 AM
>>>> To: Paul Burba
>>>> Cc: dev@subversion.tigris.org; cmpilato@tigris.org
>>>> Subject: Re: Partial fix for merge_tests.py 66 failure on
>>>> mergeinfoless-copies branch
>>>>
>>>> Paul Burba wrote:
>>>>> Try out this patch, it should fix the problem you
>> mentioned -- the
>>>>> trick is *removing* paths from expected_disk rather than
>>>> tweaking them
>>>>> -- I knew I'd run afoul of this before, it just took a long
>>>> while to
>>>>> recall what the fix was :-(
>>>> Ah... gotcha!
>>>>
>>>>> Unfortunately merge test 66 still fails on the last reverse
>>>> merge, the
>>>>> A_COPY ends up with no mergeinfo, rather than it's pristine empty
>>>>> mergeinfo. I hven't had a chance to look into that any
>> further yet.
>>>> Isn't that due to elision?
>>>>
>>>> I'm not convinced it's correct,
>>>> but isn't that the likely cause?
>>> Ah, now I understand what you meant by your comment in
>> merge test 66.
>>> And yes, its svn_client__elide_mergeinfo() that is removing the
>>> mergeinfo at the end of do_merge().
>>>
>>> There is something obviously wrong with the elision code
>> since there
>>> is nowhere for any mergeinfo on 'A_COPY', whatever it may
>> be, to elide to!
>>> I'll fix that.
>
> Gotta backpedal a bit on the "obviously wrong" statement. If a PATH has
> empty mergeinfo, that is,
>
> Properties on 'PATH':
> svn:mergeinfo :
>
> What does this actually mean? On trunk it means that PATH has had
> nothing merged into it either directly or indirectly nor has any implied
> mergeinfo from a copy.

On trunk, doesn't this only happen in the wc-to-wc copy case, and only then
because we don't want to fetch merginfo from the server?

> Now what if PATH has no parent, either in the WC
> or the repository, with explicit mergeinfo (i.e. PATH can't possibly
> inherit any mergeinfo). And then what if we remove the mergeinfo from
> PATH, what can we say about PATH now? The same thing no? PATH has had
> nothing merged into it. Since the two scenarios are semantically
> equivalent and we want to minimize the amount of explict mergeinfo, the
> mergeinfo on PATH elides (to nowhere in this case).
>
> Now take this example out of trunk and into the mergeinfoless branch.
> Once again PATH has empty mergeinfo. What does that mean? Now it just
> means that nothing merged into PATH. The concept of implied mergeinfo
> no longer exists, since that info is in PATH's natural history. Now, if
> we remove all mergeinfo from path, does that affect PATH's natural
> history? It shouldn't(?). But does the mergeinfoless branch rely in
> some way on a PATH having exlplicit mergeinfo, even if it is empty, to
> cue a lookup of PATH's natural history? If so then we don't want to
> elide empty mergeinfo, if not then I'd argue it can elidge safely.

The mergeinfoless-copies branch *always* consults natural history in any
place it also consults explicit mergeinfo. If that explicit mergeinfo is
empty, it just means there's nothing to add to the natural history to get
the full ancestry set of the object we're querying.

> Not to belabor the point, but if the mergeinfoless branch considers a
> PATH's natural history regardless of whether PATH has explicit mergeinfo
> or not, then I think the current elision behavior is correct. If not,
> then some adjustments need to be made, e.g. don't elide empty mergeinfo
> on PATH ever (or at least not if path is a copy).

Okay. Well, as I stated above, that's exactly what this branch does.

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on Wed Nov 21 20:49:28 2007

This is an archived mail posted to the Subversion Dev mailing list.