我们在Solaris 10上使用SVN 1.7。最近，我们推出了压缩的增量备份。
$ svnadmin dump --quiet --incremental --revision 0:30700 /path/to/repo > /path/to/dump
$ gzip -1 /path/to/dump
最终的gzip转储文件比原始转储文件（~500MB）大（~850MB）。我也尝试过gzip -9，但它仍然创建了一个比原始文件（~650MB）更大的文件。
很遗憾，您没有描述存储库的结构和内容。
可能，您存储的数据已经使用高效的压缩算法（例如，7z/LZMA）进行了压缩。
这些数据将出现在svnadmin dump数据流中，无法使用gzip进一步压缩，从而导致文件大小增加。
无损数据压缩算法不能进一步大幅压缩已经压缩或加密的数据。如果你有一个算法可以保证收缩其输入数据，你可以反复应用它，将数据压缩到一个字节，这显然是不可能的。
无损压缩算法通过去除输入数据中的冗余来工作，并且在应用该算法之后，该冗余已经显著减少，使得压缩算法的后续应用将不能有太大变化。
事实上，根据所使用的压缩算法及其输出数据格式，由于算法注入的控制和转义信息，结果数据大小可能会增加。
您可以尝试使用--deltas选项调用svnadmin，该选项将只输出每个修订中不同的数据，因此基本上是在修订之间进行修补。如果没有--deltas，它将输出更改文件的完整数据。
但是，如果您正在管理存储库中已经压缩的文件，这不会有太大（或任何）区别，因为压缩数据也无法正确区分。（存在一些修改后的压缩算法，例如带有--rsyncable参数的修补gzip版本或与gzip兼容的pigz工具，这些算法在一定的限制下允许这样做，并以牺牲压缩效率为代价。）
您可能试图使用您提供的--incremental标志来完成此操作，但这意味着其他事情。仅当转储修订范围时才相关，并且仅控制第一个修订是否包含此修订的完整转储或仅包含在此修订中更改的文件。因此，如果您从修订版0转储，它不会有任何效果。