爲什麼壓縮的Subversion轉儲文件比原來大？

我們在Solaris 10上使用SVN 1.7。最近我們引入了壓縮增量備份。爲什麼壓縮的Subversion轉儲文件比原來大？

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

最終的壓縮轉儲文件比原始轉儲文件（〜500MB）大（〜850MB）。我也試過gzip -9，但是它仍然會創建比原始文件（〜650MB）更大的文件。

來源

2013-11-21 Powerful Weapon

Ew，壞的編輯使gzipped轉儲比原來的更小... – crashmstr

我試圖修復以前的編輯，讓它再次有意義... – crashmstr

儘管如上所述，這看起來更像是一般的，非編程問題（因爲它處理壓縮和生成的文件大小）。可能的答案 - [爲什麼7個文件大於原始文件？]（http://superuser.com/questions/464315/why-is-a-7zipped-file-larger-than-the-raw-file）， [Google搜索]（https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=compressed%20file%20larger%20than%20original） – crashmstr

不幸的是，您沒有描述存儲庫的結構和內容。

可能地，你存儲其已經與一個有效的壓縮算法壓縮的數據（如，例如。7Z/LZMA）。

此數據將出現在svnadmin dump數據流中並且不能用gzip進一步壓縮，導致文件大小增長。

無損數據壓縮算法不能進一步收縮已經壓縮或顯著加密的數據。如果你有一個可以保證縮減輸入數據的算法，你可以直接應用它來將數據縮減爲單個字節，這顯然是不可能的。

無損壓縮算法通過在輸入數據中去除冗餘的工作，以及將所述算法之後該冗餘已顯著降低，使得壓縮算法後續應用將不能夠太大變化。

實際上，根據所使用的壓縮算法和它的輸出數據格式，所得到的數據大小將可能增長由於控制和由該算法注入逸出信息。

你可以嘗試調用svnadmin和--deltas選項，它將只輸出每個版本中不同的數據，所以基本上修補版本之間的補丁。沒有--deltas它將輸出已更改文件的完整數據。

但是，如果你在你的倉庫管理已經壓縮的文件，這樣也賺不到多少（或）還是有區別一樣，也壓縮數據無法正確顯示差異。（一些修改壓縮算法存在例如像。修補gzip的版本，以與--rsyncable參數或用gzip兼容pigz工具，它允許這種具有一定的侷限性，並在壓縮效率爲代價的。）

你也許試過這樣做你提供的--incremental標誌，但這意味着別的東西。只有在轉儲修訂版本範圍時才相關，並且只有在第一個修訂版本包含此修訂版本的完整轉儲文件或僅包含此修訂版本中更改的文件時纔會進行控制。所以如果你從版本0轉儲，它不會有任何影響。

來源

2017-04-17 11:00:47

爲什麼壓縮的Subversion轉儲文件比原來大？

回答

相關問題