Philip Martin wrote on Thu, Aug 03, 2017 at 19:01:16 +0100:
> Given unzipped data U there is no single, canonical, compressed form Z
> that represents U. Instead there are multiple forms Z1, Z2, ... that
> all expand to U. If the client sends Z1 there is no guarantee that the
> server will be abl
Paul Hammant writes:
> Git doesn't store deltas, and uses a DEFLATE algorithm for
> storage. Diffs are meaningless on binary files, of course.
I don't know about git but Subversion does quite a good job on some
binary files. Take the compressed tarballs of a couple of Subversion
tags:
$ svn
>
>
>
> We got similar benefits at my former employer when we stored JAR files in
> SVN (archival of old revisions); especially small patches and hotfixes with
> only a few changed class files were transferred and stored efficiently.
>
> You could also transparently transform the zip into an uncomp
Hi, Paul,
From: Paul Hammant [mailto:p...@hammant.org]
> > You are not the first to ask for this, but it is significantly more
> > complex than just a backend setting. []
> Yup, I didn't think about the SHA1 being different. I'll implement it
> client-side, just ignore this request.
Note
>
>
> You are not the first to ask for this, but it is significantly more
> complex than just a backend setting. []
>
Yup, I didn't think about the SHA1 being different. I'll implement it
client-side, just ignore this request.
-ph
Paul Hammant writes:
> It would be great if there were a setting somewhere like:
>
> unzip_these_suffiixes_on_serverside_but_reconstitute_zipped_form_for_client_interop:
> docx, xlsx, pptx
>
> (or 'unzip_rezip_suffixes')
>
>
> So Subversion gets to store the text forms (rather than the zip), with
6 matches
Mail list logo
