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

时间:2013-07-06 08:29:01

标签: version-control compression

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

如果是这样,有没有一种标准的方法来实现它? (也许是一个标准的预提交钩子,它将每个这样的文件解压缩到一个特别命名的文件夹中; 和一个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文件实际上是zip压缩容器,里面有一些XML文件。 (我听说许多其他流行的应用程序“二进制文件格式”也是某种形式的zip压缩文件)。

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

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

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

1 个答案:

答案 0 :(得分:1)

  

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

特别是如果你需要分支和差异,这是有道理的。

old thread总结了这种情况。

  
      
  1. 对于大小主要由嵌入图像和其他大型对象控制的Openoffice文档,git delta机制已经表现得相当好,因为OO文件是Zip压缩文件,其中每个文件都是单独压缩的。
      如果您不更改图像,那么该图像将以相同的方式保存   delta可以完成。
  2.   
  3. 对于大小以普通内容为主的OO文档,git delta机制无法工作,因为zip压缩引入了“混合”,文档中的一个小变化转换为zip文件中的一个非常大的变化。
  4.         

    可以在提交之前写一个clean过滤器来解压缩   但是,在结帐时使用补充smudge过滤器是一种技巧。如果你没有正确涂抹,git总是会将文件显示为索引更改的文件   正确涂抹意味着使用OO使用的压缩比和压缩方法,这可能有点棘手。我已尝试在cleansmudge阶段使用zip二进制文件,但它不能很好地工作。污迹文件总是与原始文件不同。
      一个应该可以在较低级别工作,以便更好地控制正在发生的事情(libzip),并在未压缩文件前面添加要在污迹上恢复的压缩参数。

         

    然而,更大的问题是,在处理大型OO文件时,干净/涂抹的东西可能会非常慢。