Thomas Denk <thomas.denk@gmail.com> writes:
> So it is perfectly correct that "svn add something --non-interactive"
> does not really make sense - there is no network involved, so there will
> never be credentials.
> Contrarily, "status" and "delete" are allowed this option, although they
> do not involve network either, which I don't understand (well, "status"
> might, if -u is given, but "delete" does not, anyway).
'svn delete URL'
> Also, while giving out a warning is certainly fine, "svn add something
> --non-interactive" will not only issue a warning, it will refuse to work
> at all.
Why shouldn't svn error if a subcommand is passed an option that it
does not take? This is standard behavior for most programs, I
thought.
> This may be intentional, and is certainly correct in that it enforces
> proper use of paramters, but I do not see what harm is there in running
> a command with an option that does nothing anyway.
CVS does the same thing; I'm pretty sure most programs do this.
> However, if the command fails, this means that when scripting svn, one
> has to keep an eye onto which commands do allow and which commands do
> not allow the option, which is a lot more complicated than necessary. If
> all commands allowed --non-interactive, a script could just append it
> every time, whether it has an effect or not.
>
> Could this failure maybe be changed to a mere warning and the option
> just be ingored?
I think it's better to be strict here. What if a command later starts
taking an option, but in such a way that it doesn't have the effect
the user expected it to have? All option passing should be
deliberate. Tolerating bad options now has the potential to cause
pain later; better to error right away.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jul 6 20:21:51 2005