Paul Burba wrote:
>> -----Original Message-----
>> From: C. Michael Pilato [mailto:email@example.com]
>> Sent: Friday, November 23, 2007 9:39 PM
>> To: firstname.lastname@example.org
>> Subject: Re: Partial fix for merge_tests.py 66 failure on
>> mergeinfoless-copies branch
>> Karl Fogel wrote:
>>> "C. Michael Pilato" <email@example.com> writes:
>>>> So ... on the mergeinfoless-copies branch, 'svn copy'
>> always results
>>>> in mergeinfo being recorded, if only empty mergeinfo. In
>> other cases
>>>> 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?
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.
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
C. Michael Pilato <firstname.lastname@example.org>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Mon Nov 26 19:13:21 2007