Support of --non-interactive option

[Thomas Denk <th...@gmail.com>]

Hi there,

The --non-interactive option is in my opinion a bit flawed in the "add"
and "revert" commands.

The documentation says:
"In the case of an authentication failure, or insufficient credentials,
prevents prompting for credentials (e.g. username or password). This is
useful if you're running Subversion inside of an automated script ..."

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).

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.
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.
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?

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Support of --non-interactive option

[kf...@collab.net]

Thomas Denk <th...@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