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

Re: RFC: Issue 2883 No-op merge (without skip) should not change mergeinfo

From: Daniel Rall <dlr_at_finemaltcoding.com>
Date: 2007-08-24 19:41:16 CEST

On Aug 22, 2007, at 5:40 PM, Mark Phippard wrote:

> On 8/22/07, Paul Burba <pburba@collab.net> wrote:
>>> We definitely want the current behavior. Perhaps if that
>>> last merge had been --depth=files then we would not want it,
>>> but otherwise we do.
>>> Revision 3 was merged into the entire tree, whether it
>>> needed to update those parts or not. For auditing reasons if
>>> nothing else, it needs to be recorded everywhere (in your example).
>>
>> Hi Mark,
>>
>> The --depth case is a separate matter, it's issue #2827 in fact.
>>
>> Anyhow, I agree with you that the current behavior is fine, but you
>> understand once issue 2883 is addressed, that if -c3 *didn't* affect
>> anything under the merge target that we will *not* update the
>> mergeinfo
>> on A_COPY, A_COPY\B, or A_COPY/C, even though "Revision 3 was merged
>> into the entire tree". I mention this because your argument "For
>> auditing reasons if nothing else" implies to me you may not agree
>> with
>> issue 2883 at all. Am I misunderstanding you?
>
> I think there is a subtle difference. 2883 is saying if there was no
> activity at all in the merge source, then we should not update the
> mergeinfo on the merge target. I realize this is only a subtle
> difference, and it could be argued that we ought to update the
> mergeinfo. In this case, it seems like a reasonable optimization to
> not do this which should be a little more friendly for scripters.
>
> In your example, there were some changes merged, they just did not
> explicitly effect the areas where the mergeinfo was updated. We
> have been fairly clear that we want this to update the mergeinfo.
>
> In fact there is third scenario, that Dan mentions on one of these
> issues. The merge does not actually merge anything, but it does
> "skip" some stuff. In other words, items were changed in the merge
> source that do not exist in the merge target. In this scenario, Dan
> was pretty adamant that we should still update the mergeinfo and I
> agree.
>
> Basically, we decided to treat the one scenario described in 2883 as a
> "special case" based on feedback from several of the early adopters
> that tried the code.

FWIW, Mark has echoed my thoughts on this thread.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 24 19:42:28 2007

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.