Subversion如何在存储库中存储文件？
我读了颠覆书，我很清楚，颠覆并不存储单个文件，但只有增量，以最大限度地减less磁盘空间。 Subversion也对二进制文件也一样（这曾经是CVS的一个巨大弱点）。
但是我不明白确切的机制。 当我提交一个文件会发生什么？
- Subversion只存储diff（并且已经有旧版本）
- Subversion删除以前的版本，保存新的文件，并创build一个反向差异，以便在需要时重新创build旧版本。
- 还有一些我没有想到的东西。
第一个案子似乎是最合乎逻辑的。 然而这又提出了另一个问题。 如果我在Subversion版本库中有一个1000提交的文件和一个新的开发者签出一个干净的副本，那么Subversion将不得不提取原始版本（初始导入），并在返回结果之前应用1000个差异。 它是否正确？ 有没有对最新版本的文件进行某种caching？
基本上我可以在哪里find关于svn仓库内部的信息？
更新：显然，颠覆的后端在这方面扮演着重要的angular色。 当时或写FSFS使用选项1，而BDB使用选项2.谢谢msemack！
由于Subversion的存储库格式完全是内部的，所以它们可以自由地将表示从一个版本更改为下一个版本。 我相信目前的版本通常会存储逆向增量（您的选项2），但是也会周期性地存储完整的快照，因此在返回结果之前不需要parsing1000个差异。
Subversion 1.6发行说明有一个关于文件系统存储改进的部分，有一些关于此的注释，并链接到其他来源。 只要说Subversion数据存储的细节是复杂的，并且可能会发生变化。
在Subversion源代码树中还有一个devise文档，它描述了在Subversion中使用skip delta 。 一般来说， / notes /目录包含了一些关于Subversion内部的有用的文档。
从Subversiondevise文档（这是相当过时，虽然），你可以得到这个：
像许多其他版本控制系统一样，Subversion将变化存储为差异。 它没有完成节点的副本; 相反，它将最新的版本存储为全文，以前的版本作为反向差异的连续存储（在这里宽松地使用“diff”这个词 – 对于文件，对于目录来说，意味着vdeltas，意思是表示对目录）。
我不认为自那以后就改变了。
另请参阅Bubble-Up方法 。
我相信下面的链接将有助于理解FSFS架构
http://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_fs/structure
常规的FSFS规范可能会对您有所帮助。
或者如果你使用Berkeley DB，那么这里就是规范。
如果我正确地理解了一切，FSFS使用反向变化来存储变化和跳过 – 增量来加速一些动作。
每次提交更改时，存储库都会存储该整个存储库树的新版本，并用新版本号标记新树。 当然，除了你改变的部分之外，大部分树与之前的版本相同。
新版本号是一个顺序标签，适用于整个新树，而不仅仅是该版本中涉及的文件和目录。 但是，通俗地说，修订号用于指修改中所做的修改; 例如，“r588的变化”（“r588”是“修订版588”的缩写）实际上是指“存储库树587和588之间的差异”，或者换言之，“对树587进行的改变以产生树588 ”。
看看： 颠覆常见问题
