在提交到存储库之前解压压缩的数据文件

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文件时，干净/污迹的事情会非常慢。