> -----Original Message-----
> From: C. Michael Pilato [mailto:firstname.lastname@example.org]
> Sent: Friday, November 23, 2007 9:39 PM
> To: email@example.com
> Subject: Re: Partial fix for merge_tests.py 66 failure on
> mergeinfoless-copies branch
> Karl Fogel wrote:
> > "C. Michael Pilato" <firstname.lastname@example.org> writes:
> >> So ... on the mergeinfoless-copies branch, 'svn copy'
> always results
> >> in mergeinfo being recorded, if only empty mergeinfo. In
> other cases
> >> besides
> >> WC->WC, so copy just go ahead and determine that, if none
> of the copy
> >> destination's parents have any mergeinfo, it should simply
> write no
> >> mergeinfo *at all*?
> > (I'm assuming 's/so/should/'.)
> > Do you mean "no mergeinfo at all besides what the copy
> source already
> > has", or do you really mean "no mergeinfo *at all*"?
> "None besides". Sorry 'bout the confusion.
Attempting to restate your comment and question:
Currently 'svn copy src dst' always results in mergeinfo being recorded
on dst, if only empty mergeinfo. But is it necessary to record empty
mergeinfo in the URL->URL, URL->WC, and WC->URL cases *if* dst has no
parent with explicit mergeinfo? Shouldn't we instead record no
mergeinfo on dst?
If that is what you are asking...
Then yes, we should not record any mergeinfo on dst. Why set override
mergeinfo when there is nothing to override?
<warning! Some obvious statements ahead, not for you, but for the
benefit of others reading this...>
Only in the WC->WC case can we not answer the question of whether there
is a parent to override or not (without contacting the repository
anyway). So in that case we should keep the empty mergeinfo to prevent
dst from inheriting incorrect mergeinfo.
That brings us back to the original purpose of this thread, that empty
mergeinfo elides after an update if it isn't overriding any parent with
explicit mergeinfo, possibly leaving local mods after an update of a
unmodified WC. This is still a possibility even if we make the changes
proposed above, since a WC->WC copy once committed can set up the same
Several of us agreed in IRC that this is incorrect and the consensus
there was to disable post-update elision. This means that we can end up
with post-update mergeinfo that is not as concise as it might be. But
it's worth noting that elision is still active during merges, so
subsequent merges to 'dst' would clean this up anyway. If no one
objects I'll make that change today.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Nov 26 18:50:25 2007