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

Re: ra_dav compression question

From: Chris Hecker <checker_at_d6.com>
Date: 2003-06-23 22:44:34 CEST

> > The above is all about server -> client stuff. He also wanted to know
> > about whether stuff from the client to the server (e.g. commits) is ever
> > gzip compressed. I assume the answer is "No", but maybe someone knows
> > for sure.

Since I'm new here, I assume the "someone" who would know reads this list?

>But I'm also not sure it matters... svn sends binary-diff data to the
>server when committing. This 'svndiff' data is already compressed via
>the vdelta algorithm. So in some sense, commits are *always*
>compressed.

A delta/diff is different from a compressed stream. Sure, it's not sending
the parts that didn't change, but the changes aren't compressed (and, as
someone said, adds are the special case where it all changes), if I
understand things correctly. Not that sending diffs isn't great, but you
really want the compression to go both ways, especially since that's part
of the reason one is supposed to use apache as the server from the manual
("wire compression for free").

A bit of reading on the apache site says that some DAV clients use client
-> server compression, so it should work in theory, but it seems like neon
would have to support that for subversion to use it transparently with
SetInputFilter, though. Hence the confusion.

And then there's the _subr compressed stream thing, which confuses me even
more.

Who can answer these questions authoritatively?

Thanks,
Chris

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 23 22:45:31 2003

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.