Re: DAV is complicated and slow?

On Mon, Nov 21, 2005 at 06:35:58PM -0600, Ben Collins-Sussman wrote:
> On 11/21/05, Justin Erenkrantz <justin@erenkrantz.com> wrote:
> > It probably
> > *does* work today with httpd 2.2 (as SVN sends the L-M headers on GET).
>
> Nope, subversion stopped using GET just before 1.0. The only commands
> that issue GET are 'svn cat' and 'svn diff/merge'. Checkouts and
> updates are a huge custom REPORT request.
>
> So, if we really want to use pipelining and caching, we'd have to
> switch back the old-styles of checkouts/updates.

If we had HTTP pipelining in the client, then hell yeah: we'd use the
old-style series of GETs and PROPFINDs.

Note that PROPFINDs are *specifically* not cacheable, per the spec.
But the GETs are absolutely cacheable. I designed the URL/resources
many, many moons ago so that we could take specific advantage of the
caching benefit.

The only thing holding us back is the pipelining. With cacheable GETs,
then a server could greatly improve its capacity by throwing a bunch
of caching reverse proxies in front of it to handle the GET load (tho
I bet mod_disk_cache is efficient enough that it can handle serious
load itself without needing to offload to proxies). But even better, a
local network (say, at a corp or school) can put up a caching proxy.
Run your SVN operatins thru that sucker, and you can share cached
copies with all your coworkers/associates/friends. First person in the
morning pulls the latest HEAD into the local cache, and then everybody
else gets their "svn up" served from that cache.

I'll also note that a lot of complexity has arisen in ra_dav due to
compatibility concerns, both with Neon compat, and with protocol
compat. ra_dav was the first RA module built and has grown a lot of
"uglies" over time. Next to WC, it is one of the oldest modules.
ra_svn is much cleaner because it learned lessons, it has a zero
impedance between svn and the protocol, and it has a cleaner protocol
compatibility mechanism.

DAV brings many feature benefits. There are definite improvements to
be made in the implementation, but the concept is (IMO) still quite
sound. I wouldn't suggest a wholesale move to REPORT requests, but
would (instead) encourage consideration of a pipelining client, thus
bringing in a number of caching benefits on a network-wide scale.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org