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: Friday, November 23, 2007 9:39 PM
>> To: dev@subversion.tigris.org
>> Subject: Re: Partial fix for merge_tests.py 66 failure on
>> mergeinfoless-copies branch
>>
>> Karl Fogel wrote:
>>> "C. Michael Pilato" <cmpilato@collab.net> 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.
>
> Mike,
>
> 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?

I'll add that to my list of things to do, then.

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

+1.

For the record, there was a suggestion that we do the elision, but only
allow it to effect nodes that already have local modifications. Personally,
I think expecting our users to grok the intricate details of what that means
is simply unreasonable, and find a no-post-update-elision-at-all solution
quite Right.

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