On Thu, Oct 29, 2009 at 5:11 PM, Ben Collins-Sussman
<sussman_at_red-bean.com> wrote:
> It's probably just the logic in the ra_dav or ra_serf client network
> module, enforcing proper webdav (and svn?) semantics. Every path
> modified/deleted/added in a commit is a whole separate request. For
> 'adds', the client is likely doing an existence check: does the path
> already exist? If so, fail the commit (the client is out of date).
> Most of the time the answer is "404", i.e. "no, it doesn't exist, so
> go ahead and PUT the file".) If this existence check didn't happen,
> then there's a risk of the PUT simply overwriting an existing object.
It'd be just as bad to send all the data and have the commit rejected
(properly) because it is out of date. That said, couldn't we add a
custom REPORT request or something where we send all these checks to
the server in one batch before we start the PUT phase? I know the
HTTP v2 stuff eliminated the PROPFIND, did it do anything like this
too? Would it be worth looking at if Kevin wanted to?
> Honestly, though: if you're worried about svn's performance over
> HTTP, stop using HTTP. It's a lost battle. HTTP is stateless, slow,
> and WebDAV is really complicated. We already rewrote it to use 30%
> fewer requests earlier this year, and I doubt it can get much leaner.
>
> If you want speed, you'll get an order-of-magnitude speedup by
> switching to svn:// instead of http://.
It sounds like glasser is rubbing off on you. :)
I still prefer HTTP for all of the things that Apache gives us. Now
that we are willing to "improve upon" WebDAV why shouldn't we consider
other opportunities to speed up our usage of HTTP?
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2412824
Received on 2009-10-29 22:30:00 CET