[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: David Glasser <glasser_at_davidglasser.net>
Date: 2007-11-07 15:33:54 CET

On 11/7/07, Paul Burba <pburba@collab.net> wrote:
> > -----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.

Pretty bikeshed!

--dave

-- 
David Glasser | glasser_at_davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 7 15:34:07 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.