On 2013-03-06 18:55:55 +0000, Julian Foad wrote:
> I don't know if anything like that would be feasible. It may be
> possible in theory but too complex in practice. The parameters we
> need to extract would include such things as the Huffman coding
> tables used and also parameters that influence deeper implementation
> details of the compression algorithm. And of course for each
> compression algorithm we'd need an implementation that accepts all
> of these parameters -- an off-the-shelf compression library probably
> wouldn't be support this.
The parameters could also be provided by the user, e.g. via a svn
property. For instance, if the user wants some file "file.xz" to
be handled uncompressed, he can add a svn:compress property whose
value is "xz -9" (if the -9 option was used). Then the client
would do a "unxz" on the file. If the user wants the bit pattern
to be preserved, the client would also do a "xz -9" on the unxz
output. If some command fails or the result is not identical to
the initial file (for preserved bit pattern), the file would be
handled compressed (or the client should issue an error message
if requested by the user). Otherwise the file could be handled
uncompressed. This is the basic idea. Then there are various
implementation choices, such as whether the commands should be
part of Subversion or external commands provided by the system.
With a property, it would not be possible to change the behavior
on past revisions, but tools could do that on a svn dump.
--
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Received on 2013-03-07 01:44:05 CET