On 12/17/07, David Glasser <glasser@davidglasser.net> wrote:
> 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'm sorry, but I missed this statement before. Could you elaborate why
this means 'putting developers first'? I think we're putting
developers of scripts first here, which IMO are users from our POV!
How would this put 'developers' (meaning 'us') first?!
> 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.
>
> 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.
For now, I too fail to see why it's (in this case) a UI wart to have
--username, --password and --non-interactive options to the svn
client. Surely I do understand it's a UI wart to support other options
(like --stop-on-copy), but I think the ones above are generic enough
to have commands suddenly develop the need for them. (See our 'sudden'
requirement for 'svn copy' to have them!)
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 17 18:02:46 2007