一、Subversion 简介
Subversion是一个“集中式”的信息共享系统，版本库是Subversion的核心部分，是数据的中央仓库；
二、版本控制模式
1.复制-修改合并方案（ 默认模式）
在这种模型里，每个客户读取项目配置库建立一个私有工作副本——版本库中文件和目录的本地映射。用户并行工作，修改各自的工作副本，最终，各个私有的复制合并在一起，成为最终的版本，这种系统通常可以辅助合并操作，但是最终要靠人工去确定正误
2.拷贝-修改-合并
在这样的模型里，在一个时间段里配置库的一个文件只允许被一个人修改
三、SVN 修订版本
1.原子事务
在工作拷贝中的一个svn commit操作可以作为一个原子事务，一个原子事务可以发布任意数量文件和目录的修改；原子事务的意思是要么所有的改变发生,要么都不发生，这类似于数据库中的事务
2.修订版本
每当版本库接受了一个提交，文件系统就进入一个新的状态，叫做一次修订（revision），每一个修订版本被赋予一个独一无二的自然数，一个比一个大，初始修订号是0，只创建了一个空目录，没有任何内容
全局版本号
不像其他版本控制系统， Subversion的修订号是针对整个目录树的，而不是单个文件。每一个修订号代表了一次提交后版本库整个目录树的特定状态，即修订号N代表版本库已经经过了N次提交。需要特别注意的是，工作拷贝并不一定对应版本库中的单个修订版本，他们可能包含多个修订版本的文件。
举例：
假如中央仓库最新修订版本号是10，用户A、B checkout此项目到各自工作拷贝中，此时他们工作目录中的三个文件对应的修订版本号如下：
1.txt ===> 10
2.txt ===> 10
3.txt ===> 10
若A对1.txt进行了修改并提交，则A的提交会在版本库中建立修订版本11，此时A的工作拷贝中所有文件的修订号如下：
1.txt ===> 11
2.txt ===> 10
3.txt ===> 10
此刻B对2.txt进行了修改并提交，则B的提交会在版本库中建立修订版本12，此时B的工作拷贝中所有文件的修订号如下：
1.txt ===> 10
2.txt ===> 11
3.txt ===> 10
但是，如果A、B二人使用 svn update 更新各自的工作拷贝后，他们二人的工作拷贝中所有文件的修订号如下：
1.txt ===> 12
2.txt ===> 12
3.txt ===> 12
注意 3.txt 在10、11、12三个修订版中的修订号是没有被改变的（没有被修改内容）。所以在工作拷贝顶级目录作一次千净的更新，会使得所有内容对应版本库的同一修订版本
3.工作拷贝如何跟踪版本库
#该命令可以查看工作目录中各个文件的版本号
svn status --verbose对于工作拷贝的每—个文件， Subversion在管理区域 .svn 目录下记录两项关键的信息：
- 工作文件所作为基准的修订版本（叫做文件的工作修订版本）
- 一个本地拷贝最后更新的时间戳
根据这些信息，通过与版本库通讯 Subversion 可以告诉我们工作文件是处于如下四种状态的那一种
- 本地工作拷贝未修改版本库未修改 ===> 文件在工作目录里没有修改，在工作修订版本之后没有修改提交到版本库。 svn commit 操作不做任何事情， svn update不做任何事情
- 本地工作拷贝未修改版本库已修改 ===> 这个文件在工作目录没有修改，但在版本库中已经修改了。这个文件最终将更新到最新版本，成为当时的公共修订版本。 svn commit不做任何事情， svn update将会取得最新的版本到工作拷贝
- 本地工作拷贝已修改版本库未修改 ===> 在工作目录已经修改，从基本修订版本之后没有修改提交到版本库。本地修改没有提交，因此 svn commit 会成功提交，svn update不做任何事情
- 本地工作拷贝已修改版本库已修改 ===> 这个文件在工作目录和版本库都得到修改。一个 svn commit将会失败，这个文件必须首先更新， svn update命令会合并公共和本地修改，如果 Subversion不可以自动完成，将会让用户解决冲突
4.工作拷贝为何会混合修订版本
Subversion有一个基本原则就是push时不会导致pull，反之亦然；这个规则的主要副作用就是工作拷贝需要记录额外的信息来追踪混合修订版本；事实上，每次运行svn commit，工作拷贝都会进入混合多个修订版本的状态，刚刚提交的文件会比其他文件有更高的修订版本号。
5.混合修订版本的优点
混合修订版本就像时间机器，可以强制工作拷贝的一部分回溯到过去；或者更新到过去的某个修订版本等等
