[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: Alan Barrett <apb_at_cequrux.com>
Date: 2005-12-08 09:53:20 CET

On Thu, 08 Dec 2005, André Pönitz wrote:
> There are basically two points coming up in the discussions:
> 1. (religious) Everybody should use text everywhere.
> 2. (semi-technical) One cannot trust clients to have proper
> filter installed, so interaction with clients may fail.

I'd add:

  3. Robust reversible filters do not yet exist for many
     of the formats of interest.

For example, if you want to manage gzipped data, you might think
"use gunzip as a filter at commit time, let the diff engine work
with uncompressed data, and use gzip as a filter at checkout time",
but you'll soon discover that "gunzip | gzip" is not actually a null
transform, and will tend to give different results every time you use
it. So different working copies might end up with different data in
files that are supposed to be identical.

There are two reasons for the failure of naive
uncompress-then-recompress filters: Compression algorithms often have
tradeoffs between time and space resources used during the compression
operation, and size of the compressed result, so different instances of
the same algorithm might make different choices (possibly depending on
factors that are not easily controlled, such as available memory at the
time the compression is performed). Also, compressed file formats often
contain metadata (such as file names and time stamps) that could change
between invocations of the same compression algorithm.

All this could be fixed by having the uncompression filter produce
output in a special format that encapsulates both the uncompressed
data and all the metadata needed to guide a subsequent recompression
filter to recreate the original compressed data. But nobody has yet
defined the special formats or implemented the secially modified
uncompress/recompress programs.

--apb (Alan Barrett)

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:58:30 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.