[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: Brian W. Fitzpatrick <fitz_at_red-bean.com>
Date: 2007-12-17 11:14:42 CET

On Dec 17, 2007 4:12 AM, <svnlgo@mobsol.be> wrote:
> 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.

I understand the why--I'm just trying to get folks to see why it's a
very bad idea to do this.

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



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:14:53 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.