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