在提交到存儲庫之前解壓壓縮的數據文件

Question

以某種方式在存儲庫中存儲「未壓縮」版本的正常壓縮文件是否有意義？

如果是這樣，是否有一個標準的方法來實現這一點？ （也許一個標準的預提交鉤子，將每個這樣的文件解壓縮到一個專門命名的文件夾中; 和一個post-checkout鉤子，將這些特殊命名的文件夾壓縮成LibreOffice知道如何讀取和寫入的壓縮文件？由"Should I decompress zips before I archive?"描述的過程？） （也許黑客版本控制軟件的代碼自動解壓縮舊版本和新版本，並在解壓縮的文件之間存儲差異，如果失敗或沒有提供顯着的改進，回到原始文件之間存儲直接差異的原始系統，還是直接存儲文件？）

我有一個經常編輯的OpenOffice/LibreOffice文件的集合。 我將它們存儲在版本控制庫中 - 按照"Should images be stored in a git repository?"的建議。 雖然我碰巧使用TortoiseHg或SourceTree來訪問我的存儲庫，而不是git。

我碰巧知道Open Office文件實際上是帶有幾個XML文件的zip壓縮容器。 （我聽說很多其他流行的應用程序「二進制文件格式」也是某種形式的zip壓縮文件）。

我的理解是即使是對這些「二進制」文件的最小改變也會導致整個新文件存儲在存儲庫中。 與「文本」文件中的小改動相反，這隻會導致更改被存儲和傳輸。

從理論上講，這將具有的優點：

• 凡變化是隻有幾句話，我可以看到的是，在更改日誌中的「差異」的觀點改變了原話。 （而不是非信息性的「二進制文件更改」消息）。
• 當幾個不同的人獨立編輯文件的版本14時，將其所有改進的所有改進合併到文件的版本16中，而不進行迴歸會更容易。
• 與遠程存儲庫更快的同步 - 只需要傳輸簡短的「更改」，而不是整個（壓縮）文件。
• 根據磁盤空間可能更小的存儲庫 - 經過幾百次更改後，我期望一個相對較小的存儲庫只包含幾百個小的更改，而不是包含這些數百個完整副本的相對較大的存儲庫文件。 （我最後列出了這個優點，因爲在這些價格便宜的磁盤空間中它幾乎是不相關的）。

Answer 1

以某種方式在存儲庫中存儲「未壓縮」版本的正常壓縮文件是否有意義？

它是有道理的，尤其是如果你需要分支和diff'ing。

這old thread總結的情況。

1. OpenOffice的文件，其大小由嵌入圖像和其它大型物體爲主，混帳三角洲機制已經表現相當不錯，因爲OO文件，每個文件分別壓縮Zip文件。
   如果您不更改圖像，那麼該圖像仍以相同的方式存儲，並且可以完成增量。
2. 對於大小主要受簡單內容影響的OO文檔，git delta機制不能工作，因爲zip壓縮引入了「混合」，並且文檔中的小變化被轉換爲zip文件中的非常大的變化。

在提交之前可能會編寫一個clean過濾器進行解壓縮。
但是，在結賬時使用補充smudge過濾器有一個竅門。如果你沒有正確塗抹，git總是顯示文件被改變了索引。
正確塗抹意味着使用OO使用的相同壓縮比和壓縮方法，這可能有點棘手。我已經嘗試在clean和smudge階段使用zip二進制，並且它不能很好地工作。污跡文件總是與原始文件不同。
應該可以在較低級別上工作，以更好地控制正在發生的事情（libzip），並在未壓縮文件前加上要在模糊時恢復的壓縮參數。

然而，更大的問題是，處理大型OO文件時，乾淨/污跡的事情會非常慢。