Subversion版本控制（2）—基础概念

版本控制基础概念

本文主要从理论上说明版本控制的原理，关于Subversion的具体操作命令将在下一篇文章中提及。个人觉得，对这些基本概念的了解有助于对subversion版本控制有更好的了解。

Subversion适用于任何类型的文件管理，并不局限于编程人员。

一、版本库（The Repository）

        版本库(The Repository)是版本控制系统的核心，它负责存储系统数据，通常存储的是类似文件系统树状结构信息（即文件和目录的层次结构信息）。如下图所示，客户端连接到repository读写文件。写文件时，客户端的写入操作需要对其他客户端可见。读文件时，客户端需要读取其他客户端对该文件的修改信息。这看起来就是一个文件服务器，客户端连接到repository通常读取到的就是最新版本的文件。但与一般文件服务器不同的是，repository不仅能读取到文件的当前版本，还能读取到文件的历史版本。

图1.1 典型的C/S系统

二、工作副本（Working copy）

        所谓工作副本就是远程的版本库文件在本地的一个拷贝，修改本地的工作副本不会影响版本库中的文件。

三、版本模型（Version Model）

        如果说版本控制系统的第一个使命是追溯不同版本的数字信息，那么它的第二个使命就是合作编辑及共享数据，在代码版本库管理中使用尤其广泛。

3.1）文件共享问题

        所有版本控制系统都面临一个基本问题：如何在用户之间共享信息，以及如何避免用户之间对共享信息的覆盖。

比如下面的这个例子：有2个项目合作者Harry和Sally，他们都打算编辑版本库中的文件A。假定Harry首先将其对文件的修改写入到版本库中，形成文件新版本A',然后Sally也将其对文件的修改写入到版本库中形成文件新版本A''，这样就导致了Sally对Harry的修改进行了覆盖。这种情况我们需要避免！！

图1.2  需要避免的情况

3.2）lock-modify-unlock解决方案

    为了让多人协同工作，许多版本控制系统使用 lock-modify-unlock模型。在 lock-modify-unlock模型中，每次只允许一个人修改一个文件。这种独占策略使用锁来实现。如图1.3所示，Harry在修改一个文件前必须锁定该文件，如果Harry锁定了该文件，则此时Sally就不能锁定该文件了，Sally此时只能读已被锁定的文件直到Harry解锁该文件为止。

该模型存在几个问题：

1）对文件加锁会导致管理上的问题。有时候Harry锁定一个文件后忘记了这件事情，则Sally就要等到花儿都谢了。如果Harry出去游山玩水了，那么Sally就需要请求管理员去解锁该文件了。这样导致了很多不必要的时间浪费。

2）对文件加锁会导致不必要的序列化问题。如果Harry只是编辑文件的前一部分，而Sally只是编辑文件的后一部分，他们对文件的修改没有重叠的地方，所以完全可以同时进行的。但是如果对文件加了锁，则另一个人就只能等待。

3）对文件加锁会构建一种安全的假象。比如Harry对文件A加锁，而与此同时Sally对文件B加锁。如果文件A和文件B相互依赖，那么这就类似于死锁了，两个文件都不再工作。

3.3）copy-modify-merge解决方案

    Subversion，CVS以及很多其他的版本系统采用的是copy-modify-merge模型。在该模型中，每个客户端联络工程仓库（repository），获取一份本地的工作副本(working copy)，然后用户们就可以使用自己的这份工作副本同时工作，对工程文件修改。最终，这些工作副本合并到一起形成一个新的、最终版本。版本控制系统辅助最终的合并过程，但是要确保合并正确，需要依赖于用户人工参与。

     图1.4 copy-modify-merge解决方案

如果Sally的修改覆盖了Harry的修改部分，则这种情况称为发生了冲突(conflict)，如何解决这个冲突，这就依赖于用户自己了。当Harry准备提交时，因为此时仓库中的版本与此前读取的版本不一致，所以会发生错误。此时Harry需要先从仓库中读取最新的文件版本并与本地的工作副本进行合并，对冲突的部分进行人工取舍，是保留自己的修改还是Sally的修改由Harry自己决定。最后她才把合并后的文件保存到仓库中。

copy-modify-merge中一个重要的因素就是：沟通。用户之间如果沟通不够，则发生语法和语义错误的可能性会大幅增加。没有系统能够强制用户能够做到完美的沟通，也没有系统能够检测语义冲突。加锁的方案能够某种程度上避免冲突，但是它并不安全；加锁只是降低了效率而已。