[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: Paul Burba <pburba_at_collab.net>
Date: 2007-11-21 20:14:28 CET

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

> > Some other questions/problems...
> >
> > If 'A_COPY's mergeinfo did have a parent to elide to, elision might
> > still occur, is this ever correct? It depends a bit on how
> copy works
> > now and gets to something I'm a bit confused on (and I
> suspect this is
> > your real question about the correctness of elision in this case):
> >
> > If we copy X to Y, and X has no explicit or
> > inherited mergeinfo, then Y has empty mergeinfo.
> >
> > Is there a scenario in which Y might correctly
> > end up with no mergeinfo or does it always need
> > at least empty mergeinfo?
>
> There are a few things about mergeinfo elision that I don't
> understand. One is this one -- should empty mergeinfo elide
> into absent mergeinfo, ever. I suspect not.

See my comments above.

> The other is about empty mergeinfo eliding into empty
> mergeinfo. Apparently you and Dan expected that to happen,
> but I'm not sure why. IIUC, empty mergeinfo means, "I don't
> want to inherit my parent's mergeinfo, regardless of what
> that mergeinfo is."

Not sure if this actually means much in practice, but I'd say instead,
"If I have *any* explicit mergeinfo then I don't want to inherit my
parent's mergeinfo". Empty mergeinfo isn't really any different from
any other type of mergeinfo in that regard that I can see.

> The fact that my parent also doesn't
> want to inherit from *his* parent does not suddenly mean that
> my own restrictions about inheritance have changed, does it?

Ok, so what if PATH and PARENT both have empty mergeinfo? The elision
code in svn_client__elide_mergeinfo() or
svn_client__elide_mergeinfo_for_tree() comes along and says, "if PATH
and it's nearest PARENT have semantically equivalent mergeinfo, PATH's
mergeinfo elides to PARENT". Again, what does this mean? Sticking with
the mergeinfoless branch for now, it means that neither PARENT nor PATH
has had anything merged into them either directly or indirectly. So if
we remove PATH's mergeinfo, it still effectively has the same mergeinfo
(i.e. nothing's been merged in!) from PARENT.

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

> [ Though, it certainly appears to indicate a very
> dysfunctional family :-) ]

The crazy child with a meat cleaver locked in the attic is partial
elision, but I'll wait till we resolve the above before letting him out
:-P

Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 21 20:14:52 2007

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