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

Re: Explaining switch_tests.py 19 failure over ra-serf (as seen on 1.6.x, and present but not typically seen on trunk)

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Thu, 29 Oct 2009 12:46:48 +0100

Greg Stein and I agree that the best approach here is for ra_serf to just
fall back to the "PROPFIND dance" instead of the "Label:" header rather than
fix mod_dav_svn. Why?

  - it's easier
  - any performance cost will be paid only by folks using pre-1.7 clients
    or hitting pre-1.7 servers
  - we've managed this long without full DeltaV support in mod_dav_svn, so
    why bother gaining more coverage now?
  - it's easier

C. Michael Pilato wrote:
> I've been looking into switch_test.py 19 failures tonight. For me, it fails
> on trunk using ra_neon, but passes using ra_serf; on the 1.6.x branch it
> fails using ra_serf, but passes using ra_neon. At the moment my attention
> is one the 1.6.x branch.
>
> I've stared at this thing for hours, and finally (at 4:30am in my current
> timezone) I see something that looks fishy. Note this request/response pair:
>
> <<<<<<<<<
> PROPFIND /svn-test-work/repositories/switch_tests-19.other/A/D HTTP/1.1
> Transfer-Encoding: chunked
> Label: 1
> Depth: 0
> Accept-Encoding: gzip
> Authorization: Basic anJhbmRvbTpyYXlqYW5kb20=
> DAV:
> http://subversion.tigris.org/xmlns/dav/svn/depth,http://subversion.tigris.org/xmlns/dav/svn/mergeinfo,http://subversion.tigris.org/xmlns/dav/svn/log-revprops
>
> Content-Type: text/xml
> User-Agent: SVN/1.6.7 (dev build) serf/0.3.0
> Host: localhost
>
> <?xml version="1.0" encoding="utf-8"?><propfind
> xmlns="DAV:"><prop><checked-in xmlns="DAV:"/></prop></propfind>
> ---------
> HTTP/1.1 207 Multi-Status
> Date: Thu, 29 Oct 2009 03:22:17 GMT
> Server: Apache/2.2.11 (Unix) DAV/2 mod_python/3.3.2-dev-20080819
> Python/2.6.2 mod_wsgi/3.0c5 SVN/1.6.7-dev
> Vary: Label
> Content-Length: 470
> Content-Type: text/xml; charset="utf-8"
>
> <?xml version="1.0" encoding="utf-8"?>
> <D:multistatus xmlns:D="DAV:" xmlns:ns0="DAV:">
> <D:response xmlns:lp1="DAV:"
> xmlns:lp3="http://subversion.tigris.org/xmlns/dav/">
> <D:href>/svn-test-work/repositories/switch_tests-19.other/A/D/</D:href>
> <D:propstat>
> <D:prop>
> <lp1:checked-in><D:href>/svn-test-work/repositories/switch_tests-19.other/!svn/ver/2/A/D</D:href></lp1:checked-in>
> </D:prop>
> <D:status>HTTP/1.1 200 OK</D:status>
> </D:propstat>
> </D:response>
> </D:multistatus>
>
> ra_serf make a request for information about a path with the "Label: 1"
> header (that is, version 1 of that thing). But we return information that
> claims that the checked-in URL for that item is ".../ver/2/..." My guess
> was that the mod_dav_svn codebase seems to indicate that the Label header is
> ignored altogether. Sure enough, if you look at mod_dav_svn/repos.c, there
> are comments in a whole bunch of URI-parsing functions which read:
>
> /* ### what to do with LABEL and USE_CHECKED_IN ?? */
>
> How did this ra_serf code ever work? More importantly, how do we fix it?
>
> This problem probably exists on trunk, too, but the test suite doesn't catch
> it without extra effort because HTTPv2 changes the way ra_serf queries a
> trunk-era server altogether. My guess is that the bug shows up here when
> talking to a pre-1.7 server (or a 1.7 server that has HTTP v2 disabled).
> I'm too exhausted to test that right now.
>
> Note that ra_neon doesn't have this problem because it takes a different
> route (with more PROPFINDs that don't try to use "Label:") to ask the same
> question of the server. Maybe that's the fix for ra_serf, too -- using
> ra_neon-like query semantics in this case?
>

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2412572

Received on 2009-10-29 12:47:10 CET

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.