> 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