One of the things that I've been looking at lately is that the svndiff
algorithm generally has lots of plain text inside of it that can be
compressed. So, I've locally tweaked ra_serf to send:
Accept-Encoding: svndiff1;q=0.9,svndiff;q=0.8,gzip
(adds in 'gzip')
This allows layered compression when updating a file (gzip plus
svndiff) and reduces the network bandwidth noticeably over just
svndiff. That's fine for 1.3 and earlier servers; but...
Yet, IIRC, this compressability issue is addressed with the new
svndiff1 algorithm in trunk. Hence, svndiff1 + gzip would not really
have any benefits - but instead just add overhead; while svndiff +
gzip does seem to have some network benefits with the extra gzip
factored in. Note that HTTP's Accept-Encoding isn't clever enough (or
I'm not seeing the way) for us to express only gzip with svndiff but
not svndiff1.
For ra_dav, what we do is base64-encode the svndiff (old or new) and
then gzip the entire report stream - so the gzip will occur
irregardless. But, ra_serf will just do a GET on the versioned
resource - so it has an opportunity to be a bit smarter about which
Accept-Encoding to send and how to ask for the response to be
compressed.
Any opinions about the right thing to do? We might be able to add
something to our OPTIONS response indicating whether the server can do
svndiff1 - ra_serf might then just not send gzip in the
Accept-Encoding request headers. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 6 03:51:21 2006