Paul Burba wrote:
> I saw that, the test still fails on Win32 though. And the builbot
> report I linked to was for r25439 (after your fix) and it reported the
> tests as passing despite the failure clearly occurring in the log.
>
Ok, there are two issues, both related to running the tests in parallel.
First is Windows specific: the exit code of a spawned process is not set correctly (when using popen3). So basically, the result of running a suite of tests is always PASS. I fixed this in r25447.
> Just check out this and you'll see what I mean:
>
> http://www.mobsol.be/buildbot/win32-xp%20VS2005/builds/1779/step-Test%20
> fsfs%2Bra_local/0
>
> I also just noticed that another test is failing:
>
> FAIL: lock_tests.py 4: commit a locked file with a prop change
>
These are the last lines of stdout:
svn: Commit failed (details follow):
svn: User jconstant does not own lock on path '/A/mu' (currently locked by jrandom)
The problem here is that when I added the option to run the tests in
parallel, I looked at and found solutions to handle shared resources,
like the current working directory and the authz file. Unfortunately
there's one shared resource which I didn't take into account, and that's
the cached credentials. What went wrong here is that another of the lock
tests used user jconstant and cached it during an svn operation, and the
failing test is committing without explicitly passing the username
(jrandom) it wants to use for the commit.
We already discussed this a few weeks ago and I don't see any other
option than disabling all credentials caching and check all 450 tests to
see if they still work. Aaaarrgh :) I'll have a look at it.
Lieven
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 18 21:22:59 2007