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=
> 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:"
> <D:status>HTTP/1.1 200 OK</D:status>
> 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
Received on 2009-10-29 12:47:10 CET