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

Posted

技术标签:

【中文标题】在提交到存储库之前解压缩压缩的数据文件【英文标题】:uncompressing zipped data files before committing to repository 【发布时间】:2013-07-06 08:29:00 【问题描述】:

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

如果是这样,是否有标准的方法来实现这一点? (也许是一个标准的预提交挂钩,将每个此类文件解压缩到一个特殊命名的文件夹中; 以及将此类特殊命名的文件夹压缩为 LibreOffice 知道如何读写的压缩文件的结帐后挂钩?类似于"Should I decompress zips before I archive?" 描述的过程?) (也许是破解版本控制软件的代码,自动解压新旧版本,并存储解压文件之间的差异,如果失败或没有显着改进,则回退到原始存储系统原始文件之间的直接差异,还是直接存储文件?)

我有一组经常编辑的 OpenOffice / LibreOffice 文件。 我将它们存储在版本控制存储库中—— 正如"Should images be stored in a git repository?" 推荐的那样。 虽然我碰巧使用 TortoiseHg 或 SourceTree 来访问我的存储库,而不是 git。

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

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

理论上,这将具有以下优点:

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

【问题讨论】:

【参考方案1】:

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

这很有意义,尤其是当您需要分支和差异时。

这个old thread总结了情况。

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

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

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

【讨论】:

以上是关于在提交到存储库之前解压缩压缩的数据文件的主要内容,如果未能解决你的问题,请参考以下文章

Unity存储数据的各种路径

linux-文件的压缩与解压缩

Hadoop支持的压缩格式对比和应用场景以及Hadoop native库

bundle文件压缩库的使用

关于文件压缩解压缩与文件加密解密的项目

关于文件压缩解压缩与文件加密解密的项目