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

Re: Confusing situation regarding revisions and changes

From: Erik Huelsmann <ehuels_at_gmail.com>
Date: 2007-09-20 18:32:41 CEST

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

bye,

Erik.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 20 18:32:54 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.