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