[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: Mark Phippard <markphip_at_gmail.com>
Date: 2007-08-23 02:40:24 CEST

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

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.

Mark Phippard
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 23 02:37:54 2007

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