on 07/31/2011 12:34 AM Andreas Krey said the following:
> The interesting point is that as far as I know there is a complete change
> in the http-level protocol coming up, to avoid the massive round-trip
> count the current method needs. (But that's a maintenance nightmare
> for libsvn as well as for anybody else writing a bare-net client.)
Now that you mention that, while analyzing strace dumps, I noticed a lot
of repeated (like 3 or 4) PROPFIND requests to the exact same URLs using
the exact same request parameters.
Maybe I am missing something but it seemed that those repeated requests
were redundant and make svn program much slower than it should. Could
that change you are talking about be meant to address these redundant
Anyway, in my implementation I did not do any repeated requests and I
can retrieve the information I want apparently much faster in PHP than
using the svn program. So I wonder if could be missing anything.
Anyway, another odd thing is that the client always sends a request
header saying it can handle HTTP compression but SubVersion servers seem
to never compress responses.
Given than a typical gzip encoding can compress text data about 5 times,
it seemed to me there is a great opportunity to make SubVersion HTTP
server accesses much faster, but that opportunity is not being addressed
because SubVersion HTTP servers do not compress responses. Again I maybe
missing something here.
Received on 2011-08-01 09:17:34 CEST