[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Proposal - option to store unzipped office documents on server side.

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Fri, 4 Aug 2017 18:52:29 +0000

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.)



> 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

This is an archived mail posted to the Subversion Dev mailing list.