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

Re: DAV is complicated and slow? (was Re: [svndiff1] Accept-Encoding in mod_dav_svn)

From: Daniel Rall <dlr_at_collab.net>
Date: 2005-11-21 22:05:00 CET

On Mon, 21 Nov 2005, Greg Hudson wrote:

> On Mon, 2005-11-21 at 18:58 +0100, Julian Reschke wrote:
> > It may be true that ra_dav currently is slow, but I think it's a bit of
> > a stretch to blame the base protocol for that. For instance, RFC3253
> > allows clients & servers to use custom REPORTs (und svn is using that),
> > so implementors *do* have the option to add extensions for performance
> > reasons.
> And we've done a lot of that. What's really to blame is trying to
> express Subversion client calls in terms of existing DAV methods.


> In a possible alternate past, we could have implemented libsvn_ra_dav
> purely in terms of custom reports, making it look a lot like ra_svn (in
> concept, not necessarily in syntax). We would probably get much better
> performance that way,

We could definitely get better performance that way.

> although we'd be throwing out any hope of using generic caching HTTP
> proxies to improve svn performance. Which is okay, since you can't
> do that today and it's unlikely anyone would be able to derive much
> benefit from it in the future.

DAV (the protocol) doesn't lend itself to being easily proxy-able.
However, losing compliance with generic DAV does have some other
noticable downsides, including loss of support (such as it is) for
auto-versioning, and ease-of-access through corporate firewalls (for
holes already punched through'em for HTTP/SSL traffic).

Daniel Rall
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 21 22:03:37 2005

This is an archived mail posted to the Subversion Dev mailing list.