版本管理模型

1 定义

版本控制（Revision Control），也被称为Version Control （System）或（Source） Code Management， 用来管理同一信息单元的不同版本。它常用于软件开发过程中，用来管理诸如源代码、文档或其它被整个开发人员所共有的资源，藉以在开发的过程中，确保由不同人所编辑的同一档案都得到更新。版本控制会记录所有对源代码或文档的改动，并会用一个数字来加以标记，这个标记被称为版本（revision）。例如：一种简单的版本控制形式如下：最初的版本指定为“1”，当做了改变之后，版本编号增加为“2”，以此类推。

2 版本管理模型

2.1 集中式模型

传统的版本管理系统都是采用集中式模型，即所有的版本控制活动都发生在一个共享的中心版本库上。如果两个开发者在同一时间下尝试更改同一份文件，并且没有采取有效措施，那么他们很可能会互相覆盖各自的改动。我们有两种方法来解决这种情况，根据解决方法的不同，集中式版本管理系统又分为两种模型：文件锁定和版本合并。

2.1.1 文件锁定

解决上述这个问题最简单的方法就是在一个时间段里版本库的一个文件只允许被一个人修改。首先在修改之前，先到的人会“锁定”这个文件，那么另一个人就无法修改这个文件，在先到的人释放这个“锁”之前，他只能阅读文件。这又被称为“锁定-修改-解锁”模型。早期的VSS就是使用这种模型。

锁定-修改-解锁模型的缺点就是限制太多：

n  如果一个人获得了“锁”，而他长时间没有释放“锁”，那么其他开发者就无法进行正常开发。

n  锁定可能导致无必要的线性化开发，如果两个开发者对同一文件的修改根本不冲突，他们完全可以同时对代码进行修改。

2.1.2 版本合并

许多版本控制系统，如CVS、Subversion， 允许许多开发者在同一时间对同一文件进行修改。第一个提交的开发者在更改完后“提交”到中心版本库时总是成功的。在其它开发者提交的时候，版本控制系统有 能力能把所有的修改合并进中心版本库。但是，如果有两个开发者的修改重叠了，那么就会引起“冲突”，这时你就会看到一组冲突集，你可以选择修改自己的代码 或和其他开发者进行协商来解决冲突。

2.2分布式模型

和集中式模型的客户-服务器的方法相反，分布式模型采用一种点对点的方法。通常的集中式管理系统，如CVS，Subversion 已经得到广泛应用，但是集中式的管理存在相应的缺陷，例如对唯一的版本库过分依赖：一旦不能正常连接到集中式的版本库，整个系统陷入瘫痪。分布式模型最大的能力就在于可以维护分布式的版本库，分散的开发人员可以通过分布式版本管理建立远程的 CVS，Subversion，P4 协议的版本库镜像，选择工作在自己合适的镜像版本库，这个镜像甚至可以是本地的，整个工作可以离线进行，然后在需要的时候同步镜像版本库到主版本库。目前，采用分布式模型的版本管理系统有Bazaar、Git、Mercurial等。

3常用术语介绍

3.1分支（Branch）

在一个时间点，复制一份处于版本控制之下的文件，从这之后，这两份拷贝就可以独立的互不干扰的进行各自开发。

3.2取出（Check-out）

一次“取出”，就是在本地创建一份仓库的工作拷贝。

3.3提交（Commit）

一次“提交”，将本地的修改写回到仓库或合并到仓库。

3.4冲突（Conflict）

 当开发者们同时提交对同一文件的修改，而且版本系统不能把它们合并到一起，就会引起冲突，就需要人工来进行合并。

3.5汇出（Export）

汇出和取出非常相似，只是汇出的文件不再处于版本控制之下，常用于发布代码。

3.6汇入（Import）

汇入就是在第一次的时候，把本地的文件拷贝到仓库中，使它们处于版本控制之下。

3.7合并（Merge）

合并就是把所有对文件的修改统一到文件里。

3.8仓库（Repository）

仓库就是当前的和历史的处于版本控制之下的文件所在的地方，通常在服务器端。

3.9工作版本（Working copy）

从档案库中取出一个本地端的复制，所有在档案库中的档案更动，都是从一个工作版本中修改而来的，这也是这名称的由来。