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

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

From: David Glasser <glasser_at_davidglasser.net>
Date: 2007-11-07 02:38:44 CET

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...

--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 02:38:57 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.