SVN教程（五）体系结构

前四节主要在说客户端，本节开始介绍更深入的配置。

我们之前的内容都是在本机设置版本库，但在多数情况下，都是多人开发的网络环境，版本库则是位于服务器之上。
先来看一下Subversion的体系结构，如图所示：



在这个图中可以看到Subversion将整个系统分成了三层。
第一层是版本库层，可以采用两种方式实现。一种是Berkeley DB，另一种是FSFS。它们的区别我们会在后续内容中介绍。
第二层我们姑且叫它访问层，是对版本库访问方式的抽象。图中定义了三种方式访问版本库，它们分别是DAV、SVN和Local。DAV是通过Apache服务器实现对版本库的访问,SVN是由subversion自带的svnserve实现对版本库的访问，最后一种Local其实就是我们前四节一直在使用的file://方式访问。
第三层就是客户层了。我们使用的svn import、commit等命令行以及TortoiseSVN，还有后面要介绍的Subversive、Subclipse等，都是属于客户端这一层。

所以实际上版本库服务器有三种运行方式，Apache、svnserve和本机直接访问。前面几节已经将本机运行讲了很多次了，我们会单独再使用使用两节来介绍Apache和svnserve。

最后再说说subversion版本库的文件结构和基本原理。
svn版本库包括以下一些目录和文件：
conf：所有配置文件，供svnserve使用
db：存储版本数据的仓库
hooks：存储hook脚本
locks：存储锁信息
format文件
readme.txt
其中format和readme.txt是文件，如果使用TortoiseSVN创建版本库，还会有一个图标。

此外，有三个目录在svn中是有着约定含义的，它们是trunk、branches和tags。注意，这里说的约定含义是针对用户的，而不是针对svn的。也就是说，用户应该在这三个目录中存储约定的内容，但svn并不约束必须要存储什么。一般来说，trunk目录存储主版本，branches中存储分支版本，而tags中则存储发布的版本。但用户将它们存储在其它目录中，也不会有什么问题。对于svn来说，没有主版本和分支版本的概念，只是与cvs相同的一种习惯延续。这段内容可能讲得不是很清楚，有时候我会单独对分支与合并进行专门介绍。

所有的版本信息会存储在db/revs目录中，svn在版本管理上使用增量复制。也就是说，每次你提交版本数据时，它虽然都创建一个新文件，但这个文件中只包含变化信息，而不会保留所有数据。因此，你不必担心版本库数据爆炸问题，而且速度也很快。此外，svn在版本管理上是针对整个目录的。也就是说，即使你只提交一个文件，整个项目的版本号都会跟着一起变化。实际上，svn会在db/revs目录中以版本号为名创建一个新文件，这个新文件中存储变化数据。