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

Re: Reliance on cached credentials in the test suite [Was: Subversion 1.4.4 tarballs up for testing/signing]

From: Lieven Govaerts <svnlgo_at_mobsol.be>
Date: 2007-05-28 07:57:51 CEST

Paul Burba wrote:
> What's the harm in relying on the cached credentials in
> local_tmp/config/auth? The spurious failure of svnadmin test 4 on 1.4.4
> is a fluke no? I'm trying to see the danger here. Was there a specific
> scenario you had in mind that could cause us problems?
There's no real harm, it's just that I want to know exactly which
resources a test requires and is using from the context. I prefer that a
test has the least possible access to external resources so it has to
make it explicit whether or not it needs, in this case, cached
credentials. The benefit is that we know for certain what a testcase is
testing - because it's made more explicit - and as such to reduce side
effects of tests as much as possible.
> Already most of the svntest.actions.run_and_verify_* methods which may
> contact the repos, with the notable exception of run_and_verify_svn,
> explicitly pass "'--username', main.wc_author, '--password',
> main.wc_passwd,", caching them in local_tmp/config/auth. That's the
> good news. The bad news is that a fix to explicitly add user & pwd
> still means looking at the 1400+ calls to actions.run_and_verify_svn().
> A brief look shows that many of these implicitly rely on cached
> credentials. But since the trunk tests do work right now, we'd be
> performing a lot of grunt work to fix...what exactly?
I don't think we can nor should change this while using the current test
framework, but rather keep this as a requirement for the next major
rewrite of it, whenever that is coming.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 28 07:58:13 2007

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