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

Re: Autoexpanding ZIP archives?

From: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2005-12-08 09:53:15 CET

On Thu, 8 Dec 2005, Peter Samuelson wrote:

> A postscript. If you really want subversion to be able to store
> deflate files efficiently, I think you really want to push for the
> 'gzip --rsyncable'[*] variant of the codec to be more widely adopted.
> It costs about 1% of compression but helps to ensure that changed bits
> in the uncompressed input stream only propagate so far before the
> output reconverges.
Cool! I was just thinking of this and did a simple experiment.

I made a 7 meg file up from concatenating some of my system binaries and
compressed it to about 3.5 megs both with and without that --rsyncable
option (it was slightly larger with --rsyncable). I committed both of
these files to a test repository.

Then I added a few bytes at the beginning of the original file and
recompressed with and without the option. I replaced the files in my WC
with the "new versions" and committed. The delta between the two files
without --rsyncable was 3 megs; as expected a small tweak made most of the
file different. The delta between the two files with --rsyncable was only
5 kilobytes which seems pretty acceptable to me:-) So for people using
gzip, this makes a big difference.

I don't think subversion should start to modify binary content and if we
can convince producers of zip or gzip'd files to make them friendly to
delta computations, that will help more tools than subversion.

Interesting experiment, anyway...

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 8 09:54:40 2005

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.