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

Question

以某种方式将正常压缩文件的"未压缩"版本存储在存储库中是否有意义？

如果是这样,有没有一种标准的方法来实现它？(也许是一个标准的预提交钩子,它将每个这样的文件解压缩到一个特别命名的文件夹中;以及一个post-checkout钩子,它将这些特别命名的文件夹压缩到LibreOffice知道如何读写的压缩文件中？类似于这个过程通过描述"我应该解压缩的拉链我归档之前？"？)(也许黑客的版本控制软件的代码,自动将解压缩旧版本,新版本和存储解压缩的文件之间的差异,如果失败或没有按"提供了显着的改进,回归原始系统存储原始文件之间的直接差异,或直接存储文件？)

我有一组经常编辑的OpenOffice/LibreOffice文件.我将它们存储在版本控制存储库中 - 如"图像是否应存储在git存储库中？"所建议的那样..虽然我碰巧使用TortoiseHg或SourceTree来访问我的存储库,而不是git.

我碰巧知道Open Office文件实际上是zip压缩容器,里面有一些XML文件.(我听说许多其他流行的应用程序"二进制文件格式"也是某种形式的zip压缩文件).

我的理解是,即使对这种"二进制"文件的最小改变也会导致整个新文件存储在存储库中.与"文本"文件中的小变化相反,这导致仅存储和传输变化.

从理论上讲,这将具有以下优势:

• 如果更改只有几个单词,我可以在更改日志中的"diff"视图中看到更改的确切单词.(而不是非信息性的"二进制文件已更改"消息).
• 当几个不同的人独立编辑文件的版本14时,将所有改进合并到文件的版本16中更容易,而不进行回归.
• 更快地同步到远程存储库 - 只需要传输短的"更改",而不是整个(压缩)文件.
• 可能更小的存储库,就磁盘空间而言 - 经过几百次更改后,我预计一个相对较小的存储库只包含几百个小的更改,而不是包含这些文件的几百个完整副本的相对较大的存储库.(我最后列出了这个优势,因为它在廉价磁盘空间的这几天几乎无关紧要).

Answer 1

以某种方式在存储库中存储正常压缩文件的“未压缩”版本是否有意义？

这是有道理的，特别是当您需要分支和比较时。

这个旧线程（死链接）（存档于此处）总结了情况：

1. 对于大小主要由嵌入图像和其他大型对象控制的 Openoffice 文档，git delta 机制已经表现得相当好，因为 OO 文件是 Zip 存档，其中每个文件都是单独压缩的。
   如果您不更改图像，则该图像仍以相同的方式存储，并且可以完成增量。

2. 对于大小以纯内容为主的 OO 文档，git delta 机制无法工作，因为 zip 压缩引入了“混合”，文档中的微小更改会转换为 zip 文件中非常大的更改。

可以编写一个clean过滤器来在提交之前解压缩。然而，在结账时使用
补充过滤器有一个技巧。smudge如果你没有正确涂抹，git 总是将文件显示为已更改的 WRT 索引。
正确涂抹意味着使用与 OO 使用的完全相同的压缩比和压缩方法，这可能有点棘手。我尝试在clean和smudge阶段中使用 zip 二进制文件，但效果不佳。弄脏的文件总是与原始文件不同。
人们可能应该在较低的级别上工作，以便更好地控制正在发生的事情（libzip），并在未压缩文件的前面添加要在弄脏时恢复的压缩参数。

然而，更大的问题是，在处理大型 OO 文件时，清理/涂抹的速度可能会非常慢。