Subversion如何在存储库中存储文件?

我读了颠覆书,我很清楚,颠覆并不存储单个文件,但只有增量,以最大限度地减less磁盘空间。 Subversion也对二进制文件也一样(这曾经是CVS的一个巨大弱点)。

但是我不明白确切的机制。 当我提交一个文件会发生什么?

  1. Subversion只存储diff(并且已经有旧版本)
  2. Subversion删除以前的版本,保存新的文件,并创build一个反向差异,以便在需要时重新创build旧版本。
  3. 还有一些我没有想到的东西。

第一个案子似乎是最合乎逻辑的。 然而这又提出了另一个问题。 如果我在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 ”。

看看: 颠覆常见问题