On Thu, 2002-08-01 at 02:03, Nick Bastin wrote:
> Except:
>
> man svn
>
> and
>
> svn man ls
>
> should tell you that. :-)
Should tell you what? You quoted my entire message; I can't tell which
part you're referring to. In case I was unclear, in my hypothetical
example, "-l" took an argument in "svn co" but not in "svn ls", so "svn
-l ls co" could be interpreted as either "svn co" with a "-l ls" switch,
or "svn ls co" with a "-l" switch. The command parser has to
arbitrarily decide which to pick, which is a bad situation.
> This is how ClearCase works, and it makes a certain amount of sense.
Once again, I have no idea what "This" means. (My masters thesis
advisor once told me that my writing would be clearer if I never used
"this" or "that" as nouns, but only as adjectives. I try to follow that
advice.)
> I agree that the cvs situation is out of control, but I think it's
> because it didn't have a consistent vision from the start. I'm not
> saying you should mimic ClearCase, but I do think that at some point
> you're going to regret not having subcommand-specific options, as the
> list of subcommands grows, and the complexities of managing options gets
> insane.
Not really. Since we are sparing with short option letters, we don't
often find ourselves wanting to use them differently in different
commands. The only case where we've kind of wished for
subcommand-specific options is "svn diff", because it's trying to mimic
a command which already has its own option syntax. For that we use the
-x flag.
We do have one sane alternative, which is to totally disallow options
between "svn" and the subcommand name--"svn ls" becomes one rigid unit,
almost as if we wanted to install separate "svnco", "svnupdate", and
"svnls" commands but didn't want to pollute the filesystem. That scheme
isn't terribly palatable, though; sometimes an option like -q "feels"
global and people want to put it right after the "svn". We don't want
to disallow that... but at the same time, we don't want -q to have a
different meaning if people list it after the subcommand.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 1 14:33:47 2002