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@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
