On Dec 16, 2007 8:47 PM, Brian W. Fitzpatrick <fitz@red-bean.com> wrote:
> While updating the reference chapter of the Subversion Book, I
> discovered that suddenly *every* command has grown --username and
> --password options. While some commands may now need authn for merge
> tracking, I found it odd that *every* command did. A little rooting
> around led me to this gem:
>
> /* Options that apply to all commands. (While not every command may
> currently require authentication or be interactive, allowing every
> command to take these arguments allows scripts to just pass them
> willy-nilly to every invocation of 'svn') . */
>
> I will strongly resist every urge to be a poisonous person here, but
> can someone please tell me why we should confuse millions of users
> just to make life easier for scripts to pass things "willy-nilly" into
> our Subversion client?
>
> I cannot believe that people find this to be acceptable. We're
> putting developers first here, and users second.
I made this change. Here was my reasoning at the time:
svnmerge.py invokes our command-line client in such a way that, if the
client tries to interact with the user, it will invisibly hang.
The addition of interactive conflict resolution to the command-line
client suddenly made it possible for "svn merge" to be interactive,
and thus for svnmerge.py to hang.
There are a few solutions here. One would be to rewrite svnmerge.py
(and any other program that wraps our client in such a way) to invoke
the CLI in such a way that the user can interact with it. However,
this may be harder than just running the script. Plus, the script may
have good reason for not wanting any interaction, even if it could be
rewritten to allow that.
Another would be to require the user to have "non-interactive = true"
in their configuration in order to use programs like svnmerge.py that
run commands like this. This would get in the way of the user using
Subversion outside the context of the script.
Finally, the script could pass --non-interactive to our client. This
is to me the best option. However, as of svn 1.4, the only
subcommands that take "--non-interactive" are the ones that currently
are capable of being interactive; passing --non-interactive to any
other subcommand is an error. This means that authors of a program
like svnmerge.py which invoke "svn" with many different subcommands
need to carefully figure out which subcommands take --non-interactive
and which do not; and worse still, if in a future version we suddently
come up with a new interactive mode in a subcommand that didn't take
--non-interactive before, the script will suddenly stop working.
Thus it seemed to me that the easiest way to allow script writers to
write fully non-interactive scripts in a forwards-compatible way was
to allow any subcommand, even those which we do not currently plan to
make interactive, take the --non-interactive switch.
Similar reasoning made me think that doing the same thing for
--username and --password is a good idea.
Perhaps "willy-nilly" was an inappropriate choice of wording, but I do
think the benefits of the change (at least the --non-interactive
change) outweigh the small costs.
--
David Glasser | glasser_at_davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 17 17:37:07 2007