On Thu, Nov 30, 2006 at 06:33:05PM -0800, Daniel Rall wrote:
> Here are the remaining test failures I'm seeing over ra_serf on Linux
> (FC5) with the latest Serf, APR, httpd 2.2.x, and Subversion (trunk):
>
> FAIL: svnsync_tests.py 1: copy and modify
> FAIL: svnsync_tests.py 2: copy from previous version and modify
> FAIL: svnsync_tests.py 3: copy from previous version
> FAIL: svnsync_tests.py 4: modified in place
> FAIL: svnsync_tests.py 9: tag with a modified file
> FAIL: svnsync_tests.py 14: verify that unreadable content is not synced
> FAIL: authz_tests.py 3: broken authz files cause errors
> FAIL: authz_tests.py 4: test authz for read operations
> FAIL: authz_tests.py 5: test authz for write operations
> FAIL: authz_tests.py 6: test authz for checkout
> FAIL: authz_tests.py 7: test authz for log and tracing path changes
> FAIL: authz_tests.py 10: test authz for aliases
>
> I'm attaching the tests.log.
FWIW, the failures I got a few weeks ago (Nov 5) was:
FAIL: svnsync_tests.py 14: verify that unreadable content is not synced
FAIL: svnsync_tests.py 15: verify that copies from unreadable dirs work
FAIL: authz_tests.py 3: broken authz files cause errors
FAIL: authz_tests.py 4: test authz for read operations
FAIL: authz_tests.py 5: test authz for write operations
FAIL: authz_tests.py 6: test authz for checkout
FAIL: authz_tests.py 7: test authz for log and tracing path changes
The authz tests are problematic because mod_dav_svn/WebDAV gives the same HTTP
error code (403) for a broken authz file versus access denied. I'm not sure
how ra_dav is determining the difference - I know it does, but it's not clear
to me how. FWIW, the authz errors are the same issue with svnsync #14/#15.
I began a patch to fix that, but it broke other stuff and I got distracted with
other things. I've attached my current patch - maybe you can pick it up. I've
forgotten why exactly I was poking around there though. =)
No clue what's up with the other svnsync tests, but they worked for me on Nov
5, but they now fail. The error from serf seems to be more indicative of the
server refusing/aborting the connection than a ra_serf failure. I'll continue
to poke around as I watch the Bengals/Ravens game.
I think at the point which we pass all of the tests is the point at which we
should flip the default in trunk. And, yes, at that point, we can cut a real
Serf release. =)
HTH. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 1 03:57:24 2006