在代码库中以某种方式存储通常压缩的文件的“未压缩”版本是否有意义？如果是这样，是否有一种标准的实现方法？（也许是一个标准的预提交钩子，将每个这样的文件解压缩到一个特殊命名的文件夹中；以及一个后检出钩子，将这些特殊命名的文件夹压缩成LibreOffice知道如何读写的压缩文件？类似于"我应该在归档之前解压缩zip文件吗?"所描述的过程吗？）（也许是通过修改版本控制软件的代码来自动解压缩旧版本和新版本，并存储解压缩文件之间的差异，如果失败或没有提供显着的改进，则回退到原始系统，存储原始文件之间的直接差异，或者简单地直接存储文件？）
我有一些OpenOffice/LibreOffice文件，需要经常编辑。我将它们存储在版本控制库中，正如"Should images be stored in a git repository?"所推荐的那样。虽然我使用的是TortoiseHg或SourceTree来访问我的存储库，而不是git。
我知道Open Office文件实际上是一个压缩了的容器，里面有几个XML文件。(我听说许多其他流行的应用程序“二进制文件格式”也是某种形式的压缩文件)。
我的理解是，即使对这些“二进制”文件进行最小的更改，也会导致整个新文件存储在仓库中。相反，“文本”文件的小改动只会导致更改被存储和传输。
理论上，这将具有以下优点：
我有一些OpenOffice/LibreOffice文件，需要经常编辑。我将它们存储在版本控制库中，正如"Should images be stored in a git repository?"所推荐的那样。虽然我使用的是TortoiseHg或SourceTree来访问我的存储库，而不是git。
我知道Open Office文件实际上是一个压缩了的容器，里面有几个XML文件。(我听说许多其他流行的应用程序“二进制文件格式”也是某种形式的压缩文件)。
我的理解是，即使对这些“二进制”文件进行最小的更改，也会导致整个新文件存储在仓库中。相反，“文本”文件的小改动只会导致更改被存储和传输。
理论上，这将具有以下优点：
- 当只有几个单词发生变化时，在更改日志的“diff”视图中，我可以看到确切的变化字词。(而不是无信息量的“二进制文件已更改”消息)。
- 当几个不同的人独立编辑文件的第14版时，更容易将他们所有的改进合并到文件的第16版中，而不会出现回归。
- 更快的与远程仓库同步--只需要传输短的“更改”，而不是整个(压缩的)文件。
- 可能更小的仓库，以磁盘空间为衡量--经过几百次更改后，我预计只包含几百个小更改的相对较小的仓库，而不是包含这些文件的几百个完整副本的相对较大的仓库。(我将这个优点列在最后，因为在如今廉价的磁盘空间时代，它几乎是无关紧要的)。