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
Also, how will a merge be done by the user?
I think we need an explicit merge subcommand,
like so:
+merge 0 1, or 2
It would work just like a 'cvs update' with
1 or 2 -j arguments. If you ask me, the -j stuff
in a cvs update is a major hack. It is really
confusing because updating with respect to
the current branch is not the same conceptual
operation as merging in changes from another
branch. These should be two different operations.
Here is what I suggest:
(This will merge all the changes made
on the branch into the HEAD)
svn merge dev-branch
If you only wanted to merge a
specific set of changes in
from a given branch, you would
pass 2 tag arguments.
svn merge dev-branch dev-branch-tag-point-11-15-01
That would merge all the changes made on
dev-branch up until dev-branch-tag-point-11-15-01
into the current code. Since svn knows what
revs have been merged already, you could run
the 1 arg version of a branch merge over
and over again without any ill effects.
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.
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?
Mo DeJong
Red Hat Inc
Received on Sat Oct 21 14:36:25 2006