[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: Branko Čibej <brane_at_xbc.nu>
Date: 2003-06-24 02:21:49 CEST

Chris Hecker wrote:

>> Quite a lot, actually. The last numbers I got are that we're within 10%
>> of "diff -e | gzip -9", and we'll beat that consistently once Dan
>> Berlin's svndiff patch goes in (i.e., once I get the time and
>> inclination to finally bring it up to date).
> That's good. Is it run on adds?

I don't believe so; I'm not too familiar with that part of the code.

> How is that compression ratio possible unless you're actually doing a
> real compression (not just diff/delta)

We are doing real compression; it's part of the vdelta algorithm.

> on it in the first place, and if you are, then why would you want
> SetOutputFilter on there anyway (since you'd risk bloating from
> double-compression, maybe, or at the very least wasting cpu trying to
> compress it again)?
>> Yeah. And I'm wondering if compressing our delta stream is really worth
>> the effort.
> Indeed. Has anyone checked to see whether using mod_deflate is a lose
> from recompressing in the first place, if it's that well compressed
> already?

It would be interesting to measure that, yes. New data (from checkouts
and added files) would definitely benefit from mod_deflate, at least
most of the time. Then there are all sorts of XML reports that compress
really well.

Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 24 02:22:37 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.