我阅读了颠覆书，我很清楚，subversion不存储单个文件，只存储增量以便最小化磁盘空间。 Subversion也对二进制文件做了同样的事情（这曾经是CVS的一个巨大弱点）。
但是我不明白确切的机制。当我提交文件时会发生什么？
第一种情况似乎最合乎逻辑。然而，这提出了另一个问题。如果我在subversion存储库中有一个包含1000个提交的文件，而一个新的开发人员检查出一个干净的副本，那么subversion必须获取原始版本（初始导入）并在返回结果之前对其应用1000个差异。它是否正确？对于保存最新版本的文件，是否存在某种缓存？
基本上我在哪里可以找到有关svn存储库内部的信息？
更新：显然，颠覆的后端在这方面发挥了重要作用。当时或写FSFS使用选项1而BDB使用选项2.谢谢msemack！
因为Subversion的存储库格式完全是内部的，所以他们可以自由地将表示从一个修订更改为下一个修订。我相信当前版本通常存储反向增量（您的选项2），但也会定期存储完整的快照，因此在返回结果之前不必解析1000个差异。
Subversion 1.6发行说明中有一个关于Filesystem storage improvements的部分，其中有一些注释，并链接到其他来源。可以说Subversion数据存储的细节很复杂，可能会有所变化。
Subversion源代码树中还有一个描述skip deltas in Subversion使用的设计文档。通常，/notes/目录包含有关Subversion内部的几个有用文档。
从Subversion Design文档（虽然相当过时）你可以得到这个：
与许多其他版本控制系统一样，Subversion将更改存储为差异。它没有完整的节点副本;相反，它将最新版本存储为全文，以及之前的版本作为一系列反向差异存储（“diff”一词在这里松散使用 - 对于文件，它表示vdeltas，对于目录，它表示表示更改的格式目录）。
我认为自那以后没有改变。
另外，请参阅Bubble-Up Method。
常规的FSFS规范可能对您有所帮助。
或者，如果你使用Berkeley DB，here's就是那个规范。
如果我正确理解了所有内容，FSFS使用反向增量来存储更改和skip-deltas来加速某些操作。
每次提交更改时，存储库都会存储该整个存储库树的新修订，并使用新的修订号标记新树。当然，除了您更改的部分之外，大多数树与之前的修订版相同。
新版本号是一个顺序标签，适用于整个新树，而不仅仅是您在该修订版中触及的文件和目录。但是，通俗地说，修订号用于表示该修订中提交的更改;例如，“r588中的变化”（“r588”是“修订版588”的简写）实际上意味着“存储库树587和588之间的差异”，或换句话说，“对树587进行更改以生成树588” ”。