我无法弄清楚为什么与大文件的小差异导致我的subversion存储库增长如此之多。
我有一个zip文件的内容是某些测试使用的数据库。我想将每个新版本的测试数据存储在我们的subversion存储库中。
我做了一些实验，检查了data.zip的最后几个版本，并查看了存储库大小的变化。未压缩的数据大约为150MB，压缩和压缩为~50MB。检入存储库的每个新版本的data.zip文件都会使存储库的大小增加大约50MB。我认为它应该只增加一个我期望更少的三角洲的数量。
Subversion使用xdelta存储压缩的差异数据。我确认SVN可以做得更好的尝试是下载xdelta并检查两个版本之间没有太大区别。确实
xdelta3.0z.x86-64.exe -e -s v1_path\data.zip v2_path\data.zip v1v2_delta.file
生成了一个大约3MB的v1v2_delta.file。
我查看了[myrepo] \ db \ revs的SVN存储库，可以查看每个新版本的大文件
02/08/2011 11:12 57,853,082 4189
02/08/2011 11:40 51,713,289 4190
02/08/2011 11:46 52,286,060 4191
（4189,4190和4191是文件的名称。）
我甚至尝试过压缩data.zip而不进行压缩。这对于SVN存储没有什么影响 - 从它的外观来看，我的猜测是它存储了每个版本的整个data.zip的压缩副本，而不仅仅是第一个。我正在运行带有FSFS后端的SVN 1.6。
有关提交二进制文件以及SVN如何存储增量的各种其他良好的stackoverflow答案，例如： SVN performance after many revisions。但是我无法从这些中看出为什么在上述情况下没有存储增量 - 即。如果xdelta可以独立运行如此小的差异，当然SVN也可以 - 或者它选择不这样做？！
编辑：我还尝试了tar（未压缩）文件，SVN也没有高效地存储它们。此外，我发现我们在不同的存储库中有一个相同数据格式的zip文件（尽管小得多），其中SVN 刚刚存储了差异。
因此，这个问题的总结版本是：SVN可以有效地存储二进制文件，例如10 slightly different CAD files are just 1.2 times the size of 1。 SVN甚至可以使用压缩的zip文件节省空间。但显然二进制文件并不总是空间有效 - 在什么条件下才是这种情况？
答案 0 :(得分：3)
<强>摘要
Subversion有时会比xdelta独立更糟糕，因为压缩会给出多少内存。这是从版本1.6开始无法更改的颠覆行为。
<强>详情
我在subversion邮件列表why the subversion repository files seemed to be bigger than they should be上询问。
结论是xdelta can produce a smaller delta if you give it more memory。
回读此帖子another example of someone else who had the same problem。
最近和四年前为此提供了信任和感谢各种人在颠覆邮件列表上的支持。
还有这个问题吗？
如果您正在分析subversion存储库的磁盘使用情况，请了解skip deltas并使用此grep DELTA trick来确定用于增量的基础。
并且假设像我一样，你确实想要在存储库中存储二进制文件，这是我对某些变通方法的猜测（没有一个非常容易！）：
答案 1 :(得分：1)
我认为压缩会彻底改变二进制文件的构成，因此svn必须存储巨大的增量。即使更改压缩文件内容的几个字符也可以彻底改变它。
在源代码管理中存储二进制文件通常是一个坏主意，我认为你应该寻找替代方案。
答案 2 :(得分：1)
在压缩存档中添加或修改文件时，压缩文件二进制内容可能会发生巨大变化。认为可能发生变化可能发生在归档的特定元素中，并且在压缩文件文件的大区域中不会发生重大变化。然而，这是一个“运气”的问题，在正常情况下会出现这种情况（当然这里没有真正的运气，但计划实现它有点复杂）
这在熵编码算法中非常正常，例如Huffman（简称为最简单的算法），因为当添加或修改文件时，符号的频率会发生变化。如果这发生在存档内容的开头，则会在更改后严重影响文件的整个内容。
答案 3 :(得分：-1)
您是否使用fsfs文件系统支持？我记得，它每次都会存储一个新副本（虽然它可能被压缩）。你为什么期望SVN存储二进制文件的差异？ SVN是一个源代码控制系统（意思是文本），而不是一般的二进制控制系统（尽管它不像存储二进制文件那样糟糕）。