下面我们将以非常常见的版本控制系统——cvs[1]为例，介绍并行版本系统一些基本的使用原理。

    代码提交和同步——从update和commit说起

    每当我们开始一个新的修改之前，首先要做的是从代码库中提取出一份最新的副本(通过update操作完成)；在本地修改、粗调之后，则应尽快将代码提交回代码库(通过commit操作完成)。

    基本的update和commit操作流程如下图所示：

    这两项操作也解决了日常开发大约80%的问题。绝大多数情况下，这部分的工作是相当简单的，除非出现两个开发者同时修改同一个文件的情况，例如，两个开发者同时地修改了同一个文件的同一个版本，这种情形称为冲突：

    可能开发者B的动作比较快，或者，修改的东西比较简单，于是他首先提交。在A、B从代码库中提取代码时，最新版本是1.1，于是，B提交的版本被版本控制系统命名为1.2。

    但不久，A想要提交代码，版本控制系统将拒绝他的提交，因为他的修改基于代码的1.1版，而目前的最新版本已经是1.2了。cvs提供了自动合并功能，允许在两个人修改的不是同一行代码的前提下，自动合并本地修改和最新的代码，当然，如果赶上两个人同时修改同一行代码的情况，cvs也会非常“聪明”地把两个“英雄所见略同”的地方合并。

    但如果两个人恰好都修改了同一行代码，而且改的不一样怎么办？cvs会告诉后一个提交的开发者发生了这样的情况，并且要求他解决问题。代码中存在的差异将以<<<和>>>标记出来，以方便进行修改。

    简单说来，当发生冲突时，我们通常约定由后一个提交者解决冲突——当然，他可以选择忽略这些冲突，但这些操作都会被记录，更何况，统计显示，同时将一行代码修改为两种不同的样子这样的情况在实际开发中很少出现。于是，修改流程继续，如下图：

图3. 开发者A解决冲突，并提交

    极端情况下，可能出现多个开发者同时修改同一个文件的问题。这一问题基本上可以按照上述的方法解决。当然，为了避免发生这样的情形，在设计的时候就应该让每个人工作的代码尽可能地不重叠。