SVN的介绍与使用流程

Subversion简单介绍

Subversion主要版本控制策略是集中式的版本控制(centralized version control),即有一个远程 的主仓库, 仓库中存放了被版本控制的数据, 用户可以在本地，操作数据的工作副本（即checkout后的项目），最终可以实现与远程仓库的通行。 

那么基于这样的一个特性，那么就有如下好处：

可以备份工作档案，相当于一台服务器；

可以进行版本控制，记录历史；
可以合作开发，共享搭档的数据；

可以节省用户空间，不需要每个版本多拷贝一份；

......

这也是大部分版本控制系统共有的特性。

Subversion 的架构

引用该图：

图中的一端是存放所有版本数据的 Subversion 仓库，另一端是 Subversion 客户端程序， 客户端程序管理着部分版本数据在本地的映射。 两端之间是穿过仓库访问 (Repository Access) 层的多条访问路径, 其中一些路径跨越计算机网络, 通过网络服务器对仓库进行访问， 其他一些路径 则不经过网络, 直接访问仓库。

基本概念

仓库

仓库通常以文件系统树 (filesystem tree ) 的形式存放信息, 有任意数量的客户端 (client) 连接到仓库, 对其中的文件进行读写 访问，如图。这里必须是要有网络的情况的，与分布式的版本控制不同（其本地有仓库）。版本控制系统的核心是仓库, 它是存放系统数据的中央位置，记录着文件变化的每个版本。

工作副本

用户如何和仓库进行交互，并访问文件数据呢？就是使用工作副本。简单就是用户checkout下来的工程，可以自由操作，没有提交前，任何操作多不会影响仓库。

版本控制模型

文件共享的问题：所有的版本控制系统都要解决一个基本问题就是， 如何允许用户共享信息, 同时避免他们无意之间互相干扰?

svn主要有这2中方案来解决这种问题：

加锁-修改-解锁 解决方案

为了解决用户间互相干扰工作的问题,，许多版本控制系统都采用了 加锁-修改-解锁 (lock-modify-unlock) 模型。在这个模型中, 仓库一次只允许一个用户修改同一文件， 这种独占策略通过锁进行管理。例如：

Harry 在修改之前要先对文件进行 “加锁” (lock)，如果 Harry 已经锁住了文件， Sally 就不能再对同一文件进行加锁，也就不能修改文件。他所能做的就是等待 Harry 完成任务然后释放锁。 Harry 解锁后才能轮到 Sally 加锁，然后他可能会得到一个新版本的文件并开始编辑。

如图，展示了工作流程：

但这种模式会有以下几种缺点：

• 加锁可能会导致管理上的问题， 有时候 Harry 在锁住一个文件后可能会忘了给它解锁, 同时 Sally 还在焦急地等着. 如果 Harry 去度假了, 那么 Sally 必须找到 仓库管理员, 让他释放 Harry 的锁. 这种情况会浪费大量的时间.
• 加锁可能会导致不必要的串行化， 如果 Harry 想要修改文件的开头部分, 而 Sally 只想修改同一文件 的结尾部分? 此时他们的修改就不会重叠. 如果他们的修改可以恰当地合并在一起, 那他们就可以同时编辑文件, 完全不会产生任何问题. 此时对文件进行加锁就完全没有必要.
• 加锁可能会造成安全上的错觉， 假设 Harry 加锁并修改了文件 A, 同时 Sally 加锁并修改了文件 B, 文件 A 和文件 B 在内容是互相依赖的, 如果 Harry 和 Sally 的 修改在语义上是不兼容的, 那将会如何? 文件 A 和文件 B 可能无法 再正常工作。加锁-修改-解锁 模型对这种情况无能为力，但是用户会错误地认为只要在加锁后修改就是安全的. 通过加锁， Harry 和 Sally 都错误地认为自己的修改是安全的, 也就不会事先和对方沟通。锁机制常常会代替真正的交流。

复制-修改-合并 解决方案

Subversion, CVS 和许多其他的版本控制系统使用 复制-修改-合并 (copy-modify-merge ) 模型作为锁机制的替代品。 在这个模型中, 每一个用户的 客户端都与仓库通信， 在本地创建一份私有的工作副本，然后用户可以同时地、互不干扰地、修改自己的私有副本，最后，私有副本被合并到一个新的最终版本。 为了支持 复制-修改-合并 模型, 版本控制系统通常会提供合并操作, 但是归根到底, 必须由用户自己来确保合并的结果是正确的。

我们通过例子来说明. 假设 Harry 和 Sally 各自创建了同一项目 的工作副本, 并在各自的工作副本中修改了同一文件 A。 Sally 先把 修改保存到仓库中, 后面 Harry 试图保存自己的修改时, 仓库告诉他 文件 A 已经 过时 (out of date ) 了, 换句话说, 自从他上一次复制了文件 A 之后， 仓库中 的文件 A 被更新了。于是， Harry 告诉客户端把仓库中文件 A 的更新合并到他的工作副本中 (这里不妨假设 Sally 的修改没有和他的修改重叠), 修改合并后, Harry 再一次向仓库保存了他自己的修改。

如图，展示了工作流程：

使用这种模式，经常会遇到的情况就是： 冲突 (conflict)。但通常不是什么大问题. 需要对它们 进行手工选择. 软件不会自动地解决冲突, 那么需要用户之间沟通之后再合并。

复制-修改-合并 模型看起来好像有点混乱, 但是在实际使用中它 运行地很流畅. 用户可以并发地工作, 不用等待其他人, 当用户操作 同一文件时, 经验表明他们的大多数修改不会重叠, 冲突情况其实很少发 生. 解决冲突花费的时间通常要比使用锁机制浪费的时间要少得多。

基本流程

官方文档上，介绍的很详细，功能也很多，但在工作中，我们比较频繁使用的功能只有其中一部分，下面先用一张图介绍工作中使用SVN的流程，对于具体的操作，将会在下一章一步一步完整介绍。如图：

大部分工作中，简单点就是这样的一个流程，只要掌握了上面的这些步骤，简单的团队工作中就可以满足了。关于图中的命令在下一章介绍。

好了，本文很多内容是借鉴文档，主要是想自己动手总结下，加深点印象。

具体参考与资料如下，大家如果想详细了解也可以详看以下资料。

http://svnbook.red-bean.com/nightly/zh/svn-book.html （版本1.8，未翻译完整）

http://svndoc.iusesvn.com/svnbook/1.4/ （版本1.4，翻译完整）