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 able to recreate Z1 from U, it might produce Z2, Z3, ...
> I suppose a version control system could be designed to allow you to
> commit Z1 and get back any of Z1, Z2, Z3, ... but Subversion makes, and
> assumes, the exact opposite: that you get back exactly what you commit.
One could define U as the repository normal form and Z1, Z2, Z3... as
the translated forms. Then, the data will be compressed in the
repository (due to svndiff1/svndiff2), on the wire (likewise), and in
the WORKING tree (due to translation). However, the text bases won't be
compressed, and 'svn cat URL_at_peg' would give the decompressed form.
And if anybody wanted to PGP-sign Z1, they'd have to exclude it from the
automatic decompression.
(In this context, "translation" is the client-side transformation that
effects svn:eol-style and svn:keywords.)
Cheers,
Daniel
> If you break that assumption changes will be necessary all through
> Subversion including, but not limited to, delta transfer, working copy
> storage, checksum verification, client post-commit processing,
> client-server compatibility, server upgrades, etc.
>
> --
> Philip
Received on 2017-08-04 20:52:36 CEST