On Jul 16, 2005, at 7:08 PM, Jean-Marc Godbout wrote:
>
> My plea to the subversion community would be to ask of anyone who has
> insight into the problem itself or how to begin solving the issue
> to let me
> know so I can probe their minds.
>
As you've seen already in the issues, there are two harsh facts
surrounding the problem of DAV network efficiency:
* DeltaV is an inherently inefficient protocol. The server wholly
defines the URL syntax for different types of objects, and the
client needs to do multiple network requests to "discover" these
opaque URLs. Being a stateless protocol doesn't help, either.
* A number of svn developers have "picked away" at the situation,
trying to reduce the number of turnarounds. We do some
client-side caching (ick) to try and help. Here and there, a
developer has discovered a way to do one less PROPFIND. But, as
you've noticed, we've not made a real dent in the problem.
A few of us have (long ago) come to the conclusion that the only
solution is to redesign ra_dav to -not- be a DeltaV client. To
understand why, you should read the latest WebDAV appendix in the
upcoming svn 1.2 book:
http://svnbook.red-bean.com/nightly/en/svn.webdav.html
Here's the really important excerpt you should read right now:
http://svnbook.red-bean.com/nightly/en/svn.webdav.svn-and-deltav.html
In other words, it's great that mod_dav_svn can speak WebDAV to 'dumb'
clients and a subset of DeltaV to svn clients. We can continue to
expand mod_dav_svn's DeltaV support in the future if we wish. But the
whole pretense of 'svn' being a DeltaV client is only hurting us, not
helping us. While the original goal might have been, "someday svn
will work against a deltaV server", I now think it's impossible.
DeltaV's model and Subversion's model just don't line up. Subversion
clients will *always* depend on custom REPORT requests to get anything
done.
Summary: we're already deriving great benefit from making mod_dav_svn
WebDAV-compliant. We're deriving zero benefit from making the svn
client 50%-deltaV-compatible. It's probably hurting us, in fact.
So here's what I'd like to see done for SoC:
1. Read the WebDAV and DeltaV specs. Understand them, love them, be
the spec. (There's a nice summary of the specs in our notes/
directory too.)
2. Read libsvn_ra_dav and watch the network traffic, so you can get
a feel for how we use DeltaV right now.
3. As an experiment, make a bunch of changes to libsvn_ra_dav which
violate DeltaV. I want libsvn_ra_dav to *assume* the structure
of all URLs, so it doesn't have to do turnarounds to discover
them. I want to see as few requests as possible. I want to see
the code vastly simplified. Feel free to ask us questions about
how to chop these things down, if you get confused.
It's the experimentation that's of real value here, not the end
result. We may discover that we get no real speedup. But at least
the research will have been done.
Jean-Marc: this may sound a bit daunting, but it's definitely a few
weeks' worth of reading and researching. You'll learn a lot!
(P.S. We try to do design discussion on this mailing list,
rather than in the issue tracker, when possible. So please post
back here with questions.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 18 16:50:08 2005