Bruce Korb <bkorb@sco.COM> writes:
> Uncle. I'll edit the README. I preferred the xx-opts.def
> files largely because it meant not having to do anything
> to get the implementation. I.e. the description and the
> implementation would be the same thing. That all assumed,
> of course, that the reading and comprehension of the
> .def files was obvious to the relatively casual reader.
> Actual invocation of the .def -> .[ch] tool was optional.
> But it does have to be a bit more rigorous and constrained
> than prose; consequently a bit more cryptic, perhaps.
> Anyway, I'll use prose.
Thank you. :-)
> The following needed to be prose anyway:
>
> there needs to be a semantic constraint on the syntax
> of the ``svn [<sub-cmd>] [<opt> ...] [<arg> ...]''.
> It is probably "obvious", but if the first argument
> to the svn command starts with a hyphen, then all the
> arguments to svn must be options from the set of common
> options. i.e.:
>
> svn <sub-cmd> [<sub-cmd-opt> ...] [<arg> ...]
> svn [ <common-opt> ... ]
>
> are the two forms.
I'm not sure I understand what you mean.
Customarily (?) this situation is handled by a special option "--" (or
whatever the convention is) that signifies the end of option
processing. That way it is possible to operate on a file whose name
is "-v", for example.
Thus:
svn update -v 132 -- -v
means update (or downdate) the file `-v' to version 132.
> In keeping with `svn' being a shell, I also propose a couple
> ``extra'' commands:
>
> exit | quit
> help
>
> the invocation: ``svn exit'' is a no-op :-), and
> the invocation: ``svn help'' gets you a command list.
> Should it also list the common options? It *is*
> distinguished from ``svn --help'', so I think not.
The shell is for the future, not 1.0. I wouldn't spend too much
mental energy on it, as we're unlikely to take the client in a
direction that is not compatible with shell-like operation later.
Best,
-Karl
Received on Sat Oct 21 14:36:12 2006