LibreOffice使用压缩的基于XML的格式，使得生成的文件相对较小，但在SVN中用于差异无用。但是，我最近了解到，平等的XML等价物（例如.ods电子表格变成了.fods扁平的XML电子表格）本质上是文本，并且可能在SVN中差异化。
现在，关于SVN中文本与二进制文件的关系通常是，如果你有一个20KB的文件并且它已被压缩，那么如果它是二进制文件，那么微小的改变将花费你另外20KB来提交;虽然它的文本只有几个字节，但只存储差异。
在我的情况下，我有一个典型的电子表格，其中.fods（平面XML）占用164KB，而.ods（压缩XML）占用18.3KB。当我添加几个单元格并保存时，做差异显示超过50％的文件发生了变化。鉴于平面XML版本为164KB，这意味着存储二进制版本实际上更有效。
所以，我错过了什么，或者这个扁平的XML事物真的效率低下了吗？
答案 0 :(得分：1)
这基本上是一个副本： Will Subversion efficiently store OpenXML Office documents?
答案仍然是正确的。有解决这个问题的工作。您可以通过Stefan's response to a similar question on the dev@subversion.apache.org list.
了解一下该线程中的格式7正在讨论FSFS格式7，即1.9.0的即将发布的部分。不幸的是，从那以后我相信Stefan对此做的工作已经从格式7中滑落（但我可能错了）并进入FSX后端，这是一个实验性的存储机制，也将出现在1.9.0中但是不会被推荐用于生产用途（但我可能错了）。
关于平面XML的问题，是的，这将有很大帮助。如果您读取整个线程（而不是我提供的单个响应），我很确定它暂时被提及为可能的解决方法。
听起来您正在使用svn diff来了解平面XML将为您提供多少存储空间。不幸的是，这对你没有多大帮助。首先，Subversion使用的二进制delta格式与统一的diff格式有很大不同。
甚至关于拉链外壳的一些假设也不是真的。仅仅因为您更改了压缩XML包的一部分并不意味着整个文件已经更改，请参阅我链接到的Stefan的电子邮件。
此外，我们不会将增量仅存储到文件的前一版本中。相反，我们使用skip delta algorithm来确定存储增量的版本，甚至有时存储全文。其目的是限制计算任何给定修订版全文的工作量。事情比1.8更复杂一点，其中有一些options for fsfs.conf that alters the skip delta algorithm。
如果你想准确了解平面文件是否有效，你应该做一些实验，看看磁盘上的存储库大小是如何增长的。