LibreOffice使用基于XML的压缩格式，使生成的文件相对较小，但在SVN中用于不同目的时没有用处。然而，我最近了解到，有一些扁平的XML等价物(例如，.ods电子表格变成了.fods扁平的XML电子表格)，它们本质上是文本，并且可能在SVN中有所不同。
现在，SVN中文本与二进制的区别通常是，如果你有一个20KB的文件，并且它是压缩的，那么如果它是二进制的，那么一个微小的更改将花费你另外20KB的时间来提交；而如果它是文本并且只存储diff，则可能只花费几个字节。
在我的例子中，我有一个典型的电子表格，其中.fods(平面XML)占164KB，.ods(压缩XML)占18.3KB。当我添加一些单元格并保存时，进行diff显示超过50%的文件发生了更改。考虑到平面XML版本是164KB，这意味着存储二进制版本实际上更高效。
那么，我是遗漏了什么，还是这种扁平的XML真的效率低下？
这本质上是以下内容的重复：Subversion能否有效地存储OpenXMLOffice文档？
那里的答案仍然是正确的。目前正在努力解决这一问题。你可以通过Stefan在dev@subversion.apache.org列表
该线程中的Format 7谈论的是FSFS Format 7，这是1.9.0即将发布的部分。不幸的是，从那时起，我相信Stefan为此所做的工作已经脱离了格式7(但我可能错了)，进入了FSX后端，这是一种实验性的存储机制，也将出现在1.9.0中，但还不推荐用于生产(但我也可能错了这一点)。
对于您关于平面XML的问题，是的，这将有很大帮助。如果你阅读了整个线程(而不是我提供的单个响应)，我很确定它会被提及为暂时的一种可能的解决方法。
听起来您正在使用svn-diff来了解平面XML将为您提供多少存储空间。不幸的是，这对你没有多大帮助。首先，Subversion使用二进制delta格式，这与统一的diff格式有很大不同。
你的一些假设，甚至是关于压缩案例的假设，都不是真的。仅仅因为您更改了压缩XML捆绑包的一部分并不意味着整个文件都会更改，请参阅我链接到的Stefan的电子邮件。
此外，我们不会仅将delta存储到文件的前一个修订版。相反，我们使用skip delta算法来确定从哪个修订版存储delta，有时甚至存储全文。这样做的目的是限制计算任何给定修订的全文所需的工作量。与1.8相比，情况稍微复杂一些，其中fsfs.conf有一些选项可以改变跳过delta算法。
如果您想准确地了解平面文件是否有效，您应该做一些实验，看看磁盘上的存储库大小是如何增长的。