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