为什么压缩的Subversion转储文件大于原始文件?

时间:2013-11-21 13:07:00

标签: svn compression gzip svndump

我们在Solaris 10上使用SVN 1.7。最近我们引入了压缩的增量备份。

$ svnadmin dump --quiet --incremental --revision 0:30700 /path/to/repo > /path/to/dump
$ gzip -1 /path/to/dump

最终的gzipped转储文件比原始转储文件(~500MB)更大(~850MB)。我也尝试了gzip -9,但仍然创建了比原始文件更大的文件(~650MB)。

1 个答案:

答案 0 :(得分:1)

不幸的是,您没有描述存储库的结构和内容。

可能,您正在存储已使用高效压缩算法压缩的数据(例如,7z / LZMA)。

此数据将显示在svnadmin dump数据流中,无法使用gzip进一步压缩,从而导致文件大小增加。

无损数据压缩算法无法进一步缩小已压缩或加密的数据。如果你有一个可以保证缩小输入数据的算法,你可以迭代地应用它来将数据缩小到一个字节,这显然是不可能的。

无损压缩算法通过消除输入数据中的冗余来工作,并且在应用算法之后,这种冗余已经显着减少,因此压缩算法的后续应用将无法发生太大变化。

实际上,根据所使用的压缩算法及其输出数据格式,由于算法注入的控制和转义信息,结果数据大小可能会增加。

您可以尝试使用--deltas选项调用svnadmin,该选项将仅输出每个版本中不同的数据,因此基本上是修订版之间的补丁。如果没有--deltas,它将输出已更改文件的完整数据。

但是,如果您在存储库中管理已压缩的文件,则不会产生太多(或任何)差异,因为压缩数据也无法正确区分。 (存在一些修改后的压缩算法,例如带有--rsyncable参数的修补gzip版本或与gzip兼容的pigz工具,这允许这具有某些限制并以牺牲压缩效率为代价。)

您可能尝试使用您提供的--incremental标记执行此操作,但这意味着其他内容。仅当您转储修订版本范围时才有意义,如果第一个修订版包含此修订版的完整转储或仅包含此修订版中更改的文件,则仅对其进行控制。因此,无论如何从版本0转储它都不会有任何影响。