Bruce Korb wrote:
> That leaves you with a rather interesting dilemma:
>
> svn -x foo bar
>
> Which is the subcommand, "foo" or "bar"?
> Well, it depends. For the "foo" subcommand, -x happens to
> require an argument, but for the "bar" subcommand, it does
> not. Or, was that the other way around? In any event,
> without knowing which is the subcommand, you cannot know
> how to handle the -x flag option.
This is completely buggered. Either -x takes an argument in all cases or it takes
no argument in all cases. Having the behavior of the option be conditional on the
command violates every option convention I can remember from anywhere. The
correct answer to the problem you pose is to have a consistent set of options in
the first place.
This sort of thing is part of why I think it's a bad idea to incorporate the
legacy command interface directly into SVN. We gotta be compatible for some
folks, but let's keep the cruft all in one place where we can shoot it all at
once later.
Oh: on the svn command echo thing: There should be an alternative script name
(qcvscompat vs. cvscompat) that doesn't do this so that existing batch scripts
can use the command translator without seeing unexpected output. It can't be a
new type of quiet option because there will prove to be scripts that do:
cvs = getenv("CVS")
exec(cvs, args, ...)
and if exec is passed
exec("cvscompat.pl -nontutorial", argcount, argvec)
it will barf.
shap
Received on Sat Oct 21 14:36:11 2006