【问题标题】:Why is the compressed Subversion dump file larger than the original?为什么压缩后的 Subversion 转储文件比原始文件大?
【发布时间】:2013-11-21 13:07:00
【问题描述】:

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

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

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

【问题讨论】:

  • Ew,错误的编辑使压缩后的转储比原始转储小...
  • 我已尝试修复之前的编辑,以使其再次有意义...
  • 尽管如前所述,这看起来更像是一个一般的、非编程问题(因为它处理压缩和生成的文件大小)。可能的答案 - Why is a 7zipped file larger than the raw file?, Google Search
  • 当数据不可压缩时,gzip 将其扩展系数不超过 1.0002(或 +0.02%)。因此,您的 500 MB 文件应该已扩展到不超过 500.1 MB。你应该仔细检查你的输入和输出。

标签: svn compression gzip svndump


【解决方案1】:

很遗憾,您没有描述存储库的结构和内容。

您存储的数据可能已经使用有效的压缩算法(例如 7z / LZMA)进行了压缩。

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

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

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

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

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

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

您可能尝试使用您提供的--incremental 标志来执行此操作,但这意味着其他东西。仅当您转储修订范围时才相关,并且仅控制第一个修订是否包含此修订的完整转储或仅包含此修订中更改的文件。因此,无论如何从修订版 0 转储它不会有任何影响。

【讨论】: