> -----Original Message-----
> From: Erik Huelsmann [mailto:ehuels@gmail.com]
> Sent: Thursday, September 20, 2007 12:33 PM
> To: Paul Burba
> Cc: Mark Phippard; Michael Pilato; Subversion Development
> Subject: Re: Confusing situation regarding revisions and changes
>
> On 9/20/07, Paul Burba <pburba@collab.net> wrote:
> > > -----Original Message-----
> > > From: Mark Phippard [mailto:markphip@gmail.com]
> > > Sent: Thursday, September 20, 2007 9:42 AM
> > > To: Erik Huelsmann
> > > Cc: Michael Pilato; Subversion Development
> > > Subject: Re: Confusing situation regarding revisions and changes
> > >
> > > On 9/20/07, Erik Huelsmann <ehuels@gmail.com> wrote:
> > > > > I am not against expanding the -c logic. As part of
> > > issue 2818, I'd
> > > > > like to see us support something like:
> > > >
> > > > > -c 10-15, 18, 21-23, 30
> > > > >
> > > > > I don't see how that factors into this issue though. Are
> > > you saying
> > > > > you would want the merge output to vary based on
> whether -r or
> > > > > -c was used?
> >
> > Please, let no one suggest that!
> >
> > > > ... No, I'd like to offer the user a way to talk to the
> > > tool the same
> > > > way the tool talks to the user. By which I mean: I think
> > > the -c option
> > > > needs to support X-Y starting 1.5. (And ofcourse, if you
> > > agree, I'll
> > > > have to put my actions where my mouth is.)
> > >
> > > Since pburba is working on 2818, we should ask if he has
> thought of
> > > this. I think he is just focusing on the API and not the command
> > > line UI that could possibly be created to use it.
> >
> > I'm still working on the API and hadn't given a lot of
> thought to the
> > CL beyond "handle everything it might throw at
> svn_client_merge_peg3()".
> > Obviously it doesn't matter much to the API, it's just
> going to handle
> > an array of svn_opt_revision_t ranges rather than a single
> range. I
> > was assuming that the CL would support something like:
> >
> > svn merge -c4,-6,8,9,10,11,12,-20,-21,-22
> >
> > or
> >
> > svn merge -r3:4,6:5,7:12,22:19
> >
> > or even both -r and -c options together
> >
> > svn merge -c4,-6 -r7:12,22:19
> >
> > I hadn't envisioned a -cX-Y syntax, but agree with Erik
> that it makes
> > sense to include it. Allowing -cX, -cX-Y -rX:Y lets the user to
> > specify what they want in the way that's easiest for them to think
> > about no? We don't want "options paralysis", but the
> minute we allow
> > cherry picking from the CL, things get a bit more complicated and
> > users will have to think about what they really want. Even if we
> > don't allow mixing of -r and -c, adding -cX-Y makes things
> appreciably worse.
>
> I was talking about adding *only* -cX-Y for now (and none of
> the other combinating variants yet).
I only described the other variants because Mark asked what I was
thinking about re Issue 2818, and that was what I was thinking about!
Sorry to muddy the waters.
> I didn't choose -cX:Y because the content of the
> svn:mergeinfo property uses X-Y... Or isn't that what you're
> talking about?
I'm not proposing -cX:Y either, I agree with you, if -c permits an
inclusive range it should be of the form -cX-Y.
In the end I was simply trying to respond to your original question,
"Fortunately, we already have a 'change' concept: the 'c' option. If we
were to extend the syntax of the 'c' option to accept '-c30-35', I would
say the situation becomes less confusing, because then, the user can
enter commands exactly the way the command line client generates its
output."
and say that I agree with you!
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 20 19:07:38 2007