You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by David Glasser <gl...@davidglasser.net> on 2007/11/06 23:03:49 UTC
Re: svn commit: r27635 - trunk/subversion/svn
On 11/6/07, pburba@tigris.org <pb...@tigris.org> wrote:
> Author: pburba
> Date: Tue Nov 6 14:35:03 2007
> New Revision: 27635
>
> Log:
> Follow-up to r27133, new help msg for svn merge's support of arbitrary
> revision ranges, a.k.a. issue #2818.
>
> * subversion/svn/main.c
> (svn_cl__cmd_table): New help text.
>
>
> Modified:
> trunk/subversion/svn/main.c
>
> Modified: trunk/subversion/svn/main.c
> URL: http://svn.collab.net/viewvc/svn/trunk/subversion/svn/main.c?pathrev=27635&r1=27634&r2=27635
> ==============================================================================
> --- trunk/subversion/svn/main.c (original)
> +++ trunk/subversion/svn/main.c Tue Nov 6 14:35:03 2007
> @@ -530,7 +530,7 @@
> ("Apply the differences between two sources to a working copy path.\n"
> "usage: 1. merge sourceURL1[@N] sourceURL2[@M] [WCPATH]\n"
> " 2. merge sourceWCPATH1@N sourceWCPATH2@M [WCPATH]\n"
> - " 3. merge [-c M | -r N:M] [SOURCE[@REV] [WCPATH]]\n"
> + " 3. merge [[-c M]... | [-r N:M]...] [SOURCE[@REV] [WCPATH]]\n"
> "\n"
> " 1. In the first form, the source URLs are specified at revisions\n"
> " N and M. These are the two sources to be compared. The revisions\n"
> @@ -549,6 +549,10 @@
> " is assumed. '-c M' is equivalent to '-r <M-1>:M', and '-c -M'\n"
> " does the reverse: '-r M:<M-1>'. If neither N nor M is specified,\n"
> " they default to OLDEST_CONTIGUOUS_REV_OF_SOURCE_AT_URL and HEAD.\n"
> + " Multiple '-c' and/or '-r' may be specified and mixing of forward\n"
> + " and reverse ranges is allowed, however the ranges are compacted\n"
> + " to their minimum representation before merging begins (which may\n"
> + " result in a no-op).\n"
I think that's a comma splice, and perhaps wants to be something like
... is allowed; however, the ranges ...
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
?
--dave
--
David Glasser | glasser@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
Re: svn commit: r27635 - trunk/subversion/svn
Posted by David Glasser <gl...@davidglasser.net>.
On 11/7/07, Paul Burba <pb...@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 <pb...@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@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
Re: svn commit: r27635 - trunk/subversion/svn
Posted by Paul Burba <pb...@collab.net>.
> -----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 <pb...@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
Re: Re: svn commit: r27635 - trunk/subversion/svn
Posted by David Glasser <gl...@davidglasser.net>.
On 11/6/07, Paul Burba <pb...@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@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
RE: Re: svn commit: r27635 - trunk/subversion/svn
Posted by Paul Burba <pb...@collab.net>.
> -----Original Message-----
> From: dglasser@gmail.com [mailto:dglasser@gmail.com] On
> Behalf Of David Glasser
> Sent: Tuesday, November 06, 2007 6:04 PM
> To: dev@subversion.tigris.org; pburba@tigris.org
> Cc: svn@subversion.tigris.org
> Subject: Re: svn commit: r27635 - trunk/subversion/svn
>
> On 11/6/07, pburba@tigris.org <pb...@tigris.org> wrote:
> > Author: pburba
> > Date: Tue Nov 6 14:35:03 2007
> > New Revision: 27635
> >
> > Log:
> > Follow-up to r27133, new help msg for svn merge's support
> of arbitrary
> > revision ranges, a.k.a. issue #2818.
> >
> > * subversion/svn/main.c
> > (svn_cl__cmd_table): New help text.
> >
> >
> > Modified:
> > trunk/subversion/svn/main.c
> >
> > Modified: trunk/subversion/svn/main.c
> > URL:
> >
> http://svn.collab.net/viewvc/svn/trunk/subversion/svn/main.c?pathrev=2
> > 7635&r1=27634&r2=27635
> >
> ======================================================================
> > ========
> > --- trunk/subversion/svn/main.c (original)
> > +++ trunk/subversion/svn/main.c Tue Nov 6 14:35:03 2007
> > @@ -530,7 +530,7 @@
> > ("Apply the differences between two sources to a
> working copy path.\n"
> > "usage: 1. merge sourceURL1[@N] sourceURL2[@M] [WCPATH]\n"
> > " 2. merge sourceWCPATH1@N sourceWCPATH2@M [WCPATH]\n"
> > - " 3. merge [-c M | -r N:M] [SOURCE[@REV] [WCPATH]]\n"
> > + " 3. merge [[-c M]... | [-r N:M]...]
> [SOURCE[@REV] [WCPATH]]\n"
> > "\n"
> > " 1. In the first form, the source URLs are
> specified at revisions\n"
> > " N and M. These are the two sources to be
> compared. The revisions\n"
> > @@ -549,6 +549,10 @@
> > " is assumed. '-c M' is equivalent to '-r
> <M-1>:M', and '-c -M'\n"
> > " does the reverse: '-r M:<M-1>'. If neither N
> nor M is specified,\n"
> > " they default to
> OLDEST_CONTIGUOUS_REV_OF_SOURCE_AT_URL and HEAD.\n"
> > + " Multiple '-c' and/or '-r' may be specified and
> mixing of forward\n"
> > + " and reverse ranges is allowed, however the
> ranges are compacted\n"
> > + " to their minimum representation before merging
> begins (which may\n"
> > + " result in a no-op).\n"
>
> I think that's a comma splice, and perhaps wants to be something like
>
> ... is allowed; however, the ranges ...
Dave,
Hmmm, I suppose that is too long of a sentence. How about skipping the
semicolon and just using two sentences?
Multiple '-c' and/or '-r' may be specified and mixing of forward
and reverse ranges is allowed. Multiple ranges are compacted to
their minimum representation before merging begins however, which
may result in a no-op.
> 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.
Paul
> --dave
>
> --
> David Glasser | glasser@davidglasser.net |
> http://www.davidglasser.net/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: svn-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: svn-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org