1. 首頁
  2. 問答
  3. Inexplicable SVN存儲庫大小從小的差異增加到大的文件

Inexplicable SVN存儲庫大小從小的差異增加到大的文件

2011-08-02 75 views
4

我不明白爲什麼與大文件的小差異導致我的Subversion存儲庫增長如此之多。Inexplicable SVN存儲庫大小從小的差異增加到大的文件

我有一個zip文件的內容數據庫使用的一些測試。我想將每個新版本的測試數據存儲在我們的Subversion存儲庫中。

我已經做了一些實驗，檢查data.zip的最後幾個版本並查看存儲庫大小會發生什麼變化。未壓縮的數據大約是150MB，壓縮後壓縮到大約50MB。每個新版本的data.zip文件都被檢入到版本庫中，這使版本庫的大小增加了大約50MB。我認爲它應該只會增加一個我預計會少得多的三角洲。

Subversion使用xdelta存儲壓縮的差異數據。我試圖確認SVN可以做得更好的是下載xdelta並檢查兩個版本之間沒有太大的區別。確實

xdelta3.0z.x86-64.exe -e -s v1_path\data.zip v2_path\data.zip v1v2_delta.file

產生了一個大約3MB的v1v2_delta.file。

我看着SVN存儲庫中的[myrepo] \ DB \轉速，可以看到大文件的每個新修訂

02/08/2011 11:12  57,853,082 4189 
02/08/2011 11:40  51,713,289 4190 
02/08/2011 11:46  52,286,060 4191

（4189的，4190和4191是文件的名稱。）

我甚至試過壓縮data.zip而不壓縮。這對SVN的商店沒有什麼影響 - 從它的角度來看，我的猜測是它爲每個版本存儲了整個data.zip的壓縮副本，而不僅僅是第一個。我使用FSFS後端運行SVN 1.6。

關於提交二進制文件以及SVN如何存儲增量的其他各種好的計算器答案，例如SVN performance after many revisions。但是我不明白爲什麼三角洲沒有存儲在上述情況下 - 即。如果xdelta可以獨立運行這樣一個小差異，SVN肯定也可以 - 或者選擇不？？

編輯：我也嘗試了tar（未壓縮）的文件，SVN不再有效地存儲它們。此外，我發現我們在SVN 剛剛存儲差異的另一個存儲庫中有一個相同數據格式的zip文件（雖然小得多）。

因此，這個問題的概括版本是：SVN可以有效地存儲二進制文件，例如， 10 slightly different CAD files are just 1.2 times the size of 1。 SVN甚至可以通過壓縮zip文件來節省空間。但顯然它並不總是節省空間的二進制文件 - 在什麼情況下是這種情況？

來源

2011-08-02 Jon Stafford

+0

關於「避免存儲二進制文件」。在Windows上，這是不可避免的，特別是如果存儲修改遊戲編輯器工件或基於辦公室的文檔。 「避免存儲容易再生的二進制文件」更爲合適。 svn可以使用二進制增量的事實將它與其他所有可用的源代碼控制系統區別開來，因爲其他所有的代碼都無法做到這一點 - 它們都會重新提交新鮮的二進制文件，這會導致文件的最終大小存儲。 – 2012-01-24 19:32:11

回答

3

摘要

顛覆有時會因爲多少內存給壓縮比xdelta獨立差。從版本1.6開始，這是目前無法更改的顛覆行爲。

詳細

我問顛覆郵件列表why the subversion repository files seemed to be bigger than they should be上。

結論是xdelta can produce a smaller delta if you give it more memory。

回覆此主題another example of someone else who had the same problem。

最近和四年前，爲此，我們感謝了各種顛覆郵件列表上的人。

還有這個問題嗎？

如果您正在分析Subversion存儲庫的磁盤使用情況，請了解skip deltas並使用此grep DELTA trick計算出用於增量的基準。

並假設，像我一樣，你確實想二進制文件存儲在庫中，這是我的一些解決方法的猜想（沒有人很容易！）：

  1. 修改顛覆源代碼和生成自己與xdelta內存設置窗口，以更大
  2. 你自己xdelta-ING - 檢查增量爲源的控制和對重建
  3. 遷移到Git的一些瘋狂的屁股過程 - 它必然有更好的壓縮（野猜測）

來源

2011-08-09 19:08:08

1

我會認爲壓縮將徹底改變二進制文件的組成，因此svn將不得不存儲巨大的delta。即使更改壓縮文件內容的幾個字符也可以徹底改變它。

在源代碼控制中存儲二進制文件通常是一個壞主意，我認爲你應該尋找替代方案。

來源

2011-08-02 19:39:42

+0

回覆：壓縮完全改變二進制文件 - 這正是我的想法，因此嘗試壓縮而不壓縮。但無論如何，我無法弄清楚的是，當從命令行單獨運行時，xdelta設法產生一個小差異。鑑於SVN使用xdelta，當然它也應該實現一個小差異？ –

+1

如果你根本不壓縮數據庫並將其存儲爲未壓縮，你會看到什麼結果？ –

+0

在其原始格式中，數據庫數據是文件夾文件的巨大樹。我可以提交這個的第一個版本。但是爲了提交第二個版本，我不能輕鬆創建一個工作副本 - 我不能僅僅將第二個版本放在第一個版本上，因爲這會弄亂所有.svn文件夾。除非有人知道一些技巧？...... –

-1

您是否使用fsfs文件系統備份？我記得，它每次都會保存一份新的副本（儘管它可能會被壓縮）。你爲什麼期望SVN存儲二進制文件的差異？ SVN是一個源代碼控制系統（意思是文本），不是一般的二進制控制系統（儘管它不像存儲二進制文件那樣糟糕）。

來源

2011-08-02 21:05:12

+0

由於Subversion 1.4 http://subversion.apache.org/docs/release-notes/1.4.html「Subversion使用xdelta算法來計算字節串之間的差異」，即。二進制文件。 –

+0

Subversion對所有東西都使用deltas。它不知道或關心這些文件是源代碼還是二進制文件。它只是對前一個回購修訂（假設FSFS）做了一個增量。 –

1

在壓縮存檔中添加或修改文件時，壓縮文件的二進制內容可能會發生急劇變化。認爲可能發生的變化可能發生在檔案的特定元素中，並且在壓縮文件文件的大部分區域中不會發生重大變化。然而，在正常情況下，這是一個「運氣」問題（當然這裏沒有真正的運氣，但是計劃實現它有點複雜）

這是很正常的熵編碼算法，如Huffman（命名最簡單的算法），因爲當添加或修改文件時，符號的頻率發生變化。如果這發生在檔案內容的開始處，則會在更改後嚴重影響文件的整個內容。

來源

2012-04-22 09:38:47 gkakas

相關問題

 相關問題