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

Re: svn commit: r27635 - trunk/subversion/svn

From: Paul Burba <pburba_at_collab.net>
Date: 2007-11-07 14:14:20 CET

> -----Original Message-----
> From: dglasser@gmail.com [mailto:dglasser@gmail.com] On
> Behalf Of David Glasser
> Sent: Tuesday, November 06, 2007 8:39 PM
> To: Paul Burba
> Cc: dev@subversion.tigris.org; pburba@tigris.org;
> svn@subversion.tigris.org
> Subject: Re: Re: svn commit: r27635 - trunk/subversion/svn
>
> On 11/6/07, Paul Burba <pburba@collab.net> wrote:
> > From: dglasser@gmail.com:
> > > I also think "which may result in a no-op" is a little
> too technical
> > > wording. Actually; I'm unconvinced that the note about
> compacting
> > > is necessary at all. I guess the actual point is that
> > >
> > > svn merge -c 123 -c 854
> > >
> > > might not be the same thing as
> > >
> > > svn merge -c 123
> > > svn merge -c 854
> > >
> > > ?
> >
> > Heh, nope, what I mean by 'no-op' is that the following never even
> > attempt to perform a merge:
> >
> > svn merge -c4 -r4:3
> >
> > svn merge -r5:12 -c-6 -r12:6
> >
> > svn merge -c5 -r3:6 -c-4 -r6:3
> >
> > FWIW, 'compacting' as I use it here means that something like this,
> >
> > svn merge -c10 -r9:10 -r5:17 -c12 -r4:14
> >
> > is just equivalent to this,
> >
> > svn merge -r4:17
> >
> > I'd like to include some language that at leasts hints to a
> user that
> > there is no magic in choosing some bizzare combination of -r/-c.
>
> Well, I mean,
>
> svn merge -c4
>
> might not perform a merge either, if the merge already is
> recorded, right? I recognize it's a totally different level
> (combining numerical quantities vs actually looking at the
> mergeinfo),

> but perhaps the main point is that the number of
> passes isn't the same as the number of -c/-r args...

That's true, but is it the "main" point? I suppose it depends who you
ask!

The help text for merge is already quite long and I want to describe the
new behavior as simply as possible. How's the following sound (taking
into consideration your comments thus far):

3. In the third form, SOURCE can be a URL, or working copy item
   in which case the corresponding URL is used. If not specified,
   the copy source URL of SOURCE is used. If the WCPATH cannot be
   determined automatically, an error is displayed asking for an
   explicit SOURCE. This URL in revision REV is compared as it
   existed between revisions N and M. If REV is not specified, HEAD
   is assumed. '-c M' is equivalent to '-r <M-1>:M', and '-c -M'
   does the reverse: '-r M:<M-1>'. If neither N nor M is specified,
   they default to OLDEST_CONTIGUOUS_REV_OF_SOURCE_AT_URL and HEAD.
   Multiple '-c' and/or '-r' may be specified and mixing of forward
   and reverse ranges is allowed. Multiple ranges are reduced to a
   minimum representation before merging begins. This means that
   fewer, or possibly no, merge passes may be performed.

Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 7 14:19:22 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.