6

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

如果是这样，是否有标准的方法来实现这一点？（也许是一个标准的预提交挂钩，将每个此类文件解压缩到一个特殊命名的文件夹中；以及一个将此类特殊命名的文件夹压缩为 LibreOffice 知道如何读写的压缩文件的结帐后挂钩？类似于过程的东西由“我应该在存档之前解压缩 zip 吗？”描述t 提供显着改进，退回到存储原始文件之间直接差异的原始系统，还是直接存储文件？）

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

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

我的理解是，即使是对此类“二进制”文件的最小更改也会导致整个新文件存储在存储库中。与“文本”文件中的小更改相反，这会导致仅存储和传输更改。

从理论上讲，这将具有以下优点：

  • 如果更改只有几个字，我可以在更改日志的“差异”视图中看到更改的确切字词。（而不是非信息性的“二进制文件已更改”消息）。
  • 当几个不同的人独立编辑文件的第 14 版时，将他们的所有改进合并到文件的第 16 版中会容易得多，而不会出现回归。
  • 更快地同步到远程存储库——只需要传输短暂的“更改”，而不是整个（压缩的）文件。
  • 可能较小的存储库，就磁盘空间而言——经过几百次更改后，我希望一个相对较小的存储库只包含几百个小更改，而不是一个相对较大的存储库，其中包含这些文件的几百个完整副本。（我最后列出了这个优势，因为在这些廉价磁盘空间的日子里它几乎是无关紧要的）。
4

1 回答 1

1

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

这很有意义，特别是如果您需要分支和区分。

这个旧线程总结了这种情况。

  1. 对于大小以嵌入图像和其他大对象为主的 Openoffice 文档，git delta 机制已经表现得相当不错，因为 OO 文件是 Zip 存档，其中每个文件都单独压缩。
    如果您不更改图像，则该图像仍以相同的方式存储，并且可以完成增量。
  2. 对于大小以纯内容为主的 OO 文档，git delta 机制无法工作，因为 zip 压缩引入了“混合”，文档中的微小变化会转换为 zip 文件中的非常大的变化。

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

然而，更大的问题是，在处理大型 OO 文件时，清理/涂抹的东西可能真的很慢。

于 2013-07-07T09:51:19.680 回答