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

Re: [PATCH] Issue 2848

From: Ben Collins-Sussman <sussman_at_red-bean.com>
Date: 2007-07-22 21:40:10 CEST

On 7/22/07, Paul Burba <pburba@collab.net> wrote:

> --- Merging r-5:
> ^
> What do people think of this? Ben, I know you discussed this a lot on
> list and IRC already, did you have a better option?

If start and end are different, then just *always* display them, i.e.

--- Merging r5 through r4:

There's nothing worrisome about this: we explain to the user over and
over in documentation that doing -r5:4 is a normal way to revert
changeset 5, and that -c-5 is just a shorthand for that. So it's not
going to shock anyone to see start > end printed in a notification.

> The one place we still find svn_merge_range_t start and end fields equal
> is when merging two different URLS (for those not following merge
> tracking closely, note that these types of merges have *no* effect on
> svn:mergeinfo),
> svn merge sourceURL1[@N] sourceURL2[@M] [WCPATH]
> where N=M or N and M are missing and default to HEAD. In this case
> grok_range_info_from_opt_revisions() returns a svn_merge_range_t with
> start == end. In this case my patch does the notifications the way it
> always has:
> --- Merging rM:
> Or, if N != M:
> --- Merging rN+1 through rM:
> Thinking about this a bit, I wonder if we shouldn't change the
> notification in these cases to something like:
> --- Merging different URLs:
> Or something else, just let the user know that svn:mergeinfo is not
> being set/updated.
> Thoughts?

I'm fine with just printing "Merging rM". But, yes, maybe we should
still print an (independent) warning that no mergeinfo data is being

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jul 22 21:39:10 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.