[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Passing unused opts to every command considered harmful

From: <svnlgo_at_mobsol.be>
Date: 2007-12-17 11:12:50 CET

Quoting "Brian W. Fitzpatrick" <fitz@red-bean.com>:

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

These options were added to stop the test suite caching credentials. First of
all this is bad practice in testing, and second this breaks running the tests
in parallel. So to solve this we have to add --username and --password options
to all invocations of svn.
Since we don't control all of those invocations it was decided to add --username
and --password to all svn commands.

It's probably possible to implement the test framework a bit different and add
those two options only to those command that need it.

Lieven

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 17 11:13:10 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.