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

Re: Client subcommands and args and targets (Oh my!)

From: B. W. Fitzpatrick <fitz_at_red-bean.com>
Date: 2001-03-14 15:37:54 CET

> On Wed, 14 Mar 2001, B. W. Fitzpatrick wrote:
>
> > Note:This is taken directly from subversion/client/TODO.
> >
> > Some notes on a subset of the client commands. These are the basics
> > that we're working on right now. Note that non-file args don't count
> > standard flags that are dealt with by get_opts.
> >
> > COMMAND # of non-file args # of file args
> > annotate 0 0, 1, or more (implicit dot)
> > commit 0 0, 1, or more (implicit dot)
> > delete 0 0, 1, or more (implicit dot)
> > status 0 0, 1, or more (implicit dot)
> > update 0 0, 1, or more (implicit dot)
> > log 0 0, 1, or more (implicit dot)
> > diff ! 0, 1, or more (implicit dot)
> > propget 1 0, 1, or more (implicit dot?)
> > propset 2 0, 1, or more (implicit dot?)
> > add 0 1 or more
> > checkout 1 or more 0
> > import 3 0
> >
> > So the mechanism that we currently have in place will handle
> > everything except for diff, which will likely have to be special cased
> > anyway since it's going to deal with (possibly, hopefully) many
> > different external diff programs.
> >
> > -Fitz
>
> I don't think that delete entry is correct. The current
> impl does not add an implicit '.'. I think that should
> be:
>
> -delete 0 0, 1, or more (implicit dot)
> +delete 0 1, or more
>
> Delete really should have a target. Say a person
> wanted to delete a directory. We would want to
> document `svn delete dir` not `cd dir ; svn delete`.
> That is not how to unix rm command works:
>
> % rm
> rm: too few arguments

I agree that it should, but the current behavior of cvs is to add the
implicit dot if you pass the -f flag to 'cvs rm'. I'm all for changing
that, though.
 
> Also, how will a merge be done by the user?
> I think we need an explicit merge subcommand,
> like so:

Hang on a second there... if you read back up, you'll see that I said
'subset' of client commands... We're going for 1.0, not beyond
that. I'm trying to focus on the core commands here until we get some
momentum going in the client.

<merge stuff elided>

> Another issue is a command where the number
> of non-target args is not a constant.
> The current approach does not deal with
> that aside from a FIXME that says it
> should be implemented later.

update your working copy... I wrote that code last night.

> If we move the option and target processing into
> the subcommands, then each subcommand can do
> whatever it needs. That would make it way
> easier to add a new subcommand that processed
> arguments in ways we have not considered
> thus far. I already tried to implement the
> 0->N and 1-N check for the target args
> in main() and it was really ugly. Since
> delete and add are the only subcommands
> that need to raise an error when 0
> targets are passed and since checkout,
> import, and the prop* commands are the
> only ones that need to process non target
> args, would it not be easier to just
> special case those arg processing
> needs in the subcommands instead of main?

That may be true, but remember that we're going to be 'canonicalizing'
the filenames:

/* kff todo: need to remove redundancies from targets before
     passing it to the cmd_func. */

What is that function going to do with non-filename args? What if a
non filename arg happens to have the same name as a file?

-Fitz
Received on Sat Oct 21 14:36:25 2006

This is an archived mail posted to the Subversion Dev mailing list.