一、配置库的检入检出机制
配置库的检入检出和版本控制机制解决了团队软件开发中的两个重要问题：
· 访问控制：保证具有相应权限的人员才能修改配置项。
· 并行控制：保证不同人员同时对某配置项进行的修改不会互相覆盖。
二、防止版本覆盖的两种方法
第一种方法：串行（加锁-解锁）。
程序员在修改文件之前，版本控制工具将文件加锁，其他人不能对它进行修改。该程序员修改完毕，将文件再检入到配置库中时，版本控制工具再将其解锁，其他人才能进行修改。
特点：效率较低，应尽量减小加锁范围。
Visual SourceSafe (VSS)，微软出品的版本控制工具，默认支持第一种方法。通过设置，也可支持第二种方法。
第二种方法：并行（修改-合并）。不同的程序员可同时修改某一文件，修改完成后，在某一合适的时刻进行合并（由版本控制工具辅助完成）。
特点：效率较高
Subversion（SVN）、ClearCase(CC)都同时支持以上两种方法，但以第二种方法为主。
市面上还有几十种版本控制工具，它们都至少支持以上两种方法中的一种。
配置项的演化图(Evolution Graph)
三、适时更新工作空间
开发人员在自己的工作空间中工作的时候，配置库中可能已有了很大的变化，其他开发人员已向配置库提交了很多代码。这样，自己的工作空间中的代码就有过时的风险，使得自己开发的代码不能与其他人最新的代码共同工作。
因此开发人员需要适时地更新（update）自己的工作空间。
Subversion中的更新就叫“update”。其它一些工具还有另外的称呼，如变基(Rebase)，重新配置(Reconfig)等。
什么时候更新？
1、在开始一个新任务的时候，如开发一个新功能模块，修改一处代码等。这时的更新建立了关于这个任务的初始工作环境。不要在一开始的时候就落伍。
2、在完成任务的过程中，可能需要更新。特别是在任务持续时间较长的情况下。要跟上时代的步伐。
3、在任务完成后，即将提交的时候，最好做一次更新，并测试一下，以保证自己新写的代码，可以与别人的代码一起工作。保证提交有基本的质量。做事要善始善终。
注意：更新工作空间也不必要太频繁。
四、记录源代码整体版本
在软件项目周期的不同时期会产生不同的版本，且在同一时期也会有不同的版本。
因此需要记录软件的整体版本，明确软件的每个版本都包含哪些特定版本的源程序文件。
记录源代码整体版本的方法：
方法一：在软件开发过程中，当某一版本形成时，复制其所有源代码。一些版本控制工具提供的复制(Copy)命令即可完成这一任务。
方法二：记录某个整体版本，只需要记录这个版本是由哪些文件的具体哪个版本组成的。因此可以在相关文件的特定版本上打个标签(Label/Tag)，标签的名字，就是整体版本的名字。
Subversion支持以上第一种方法。此外，Subversion总是自动地产生新的整体版本。程序员的每一次提交，都会产生一个新的源代码整体版本号，将这一整体版本号分配给所有源程序文件。因此Subversion实际上也支持以上第二种方法。
ClearCase采用的是第二种方法。
基线及其质量状态
在谈论源代码版本管理的时候，基线（Baseline）的含义是，被明显地标志和记录下来的源代码整体版本。
基线具有质量状态：
刚刚标记出来的时候，其质量未知（Initial）；
编译链接和打包通过后，其质量是通过构建的（Built）；
如果通过了一定程度的测试，其质量是通过测试的（Tested）；
如果通过了详尽测试，可以发布，其质量是可发布的（Released）。
当基线由一个较低的质量状态达到了一个更高的质量状态时，就产生了一个基线提升（Baseline Promotion）。
Subversion可以用版本属性来表示基线的质量状态。
ClearCase UCM明确地支持基线提升。不仅有相应的命令，也可以在图形界面中操作和查看。
五、保存安装包
在发布软件之前，或在对软件进行系统测试或验收测试之前，需要生成安装包。安装包同样需要保存，并标上相应的版本号，原因如下：
1、将来在需要该安装包时，可以迅速准确地得到它，不必从源代码开始重新编译、打包，这样可以节省时间。
2、用户或系统测试人员发现的软件Bug，有可能是由安装包的生成过程造成的，保存了安装包，可以快速地定位Bug的原因。
ClearCase不仅存储和管理源代码，也存储和管理由源代码生成的内容，这些内容被称为“导出对象”（Derived Object），包括可执行文件、库文件、数据文件等。安装包也是导出对象的一种。
六、软件版本编号方法
源代码文件、文档文件和产品整体（源代码整体和安装包）都有版本号（Version Number）。
版本号的命名，目前业界尚无统一做法。
1、产品整体版本编号
· 数字顺序型版本编号
-普通版本编号
-α和β版本编号
· 属性版本编号
配置管理工具的自动版本编号
数字顺序型版本编号
2、普通版本编号
产品的版本号由若干数字组成，数字之间用“.”分隔。一种典型的编号策略如下：
x.y.z，x为主版本号，y为特征版本号，z为缺陷修复版本号。
1)主版本号的增加表示提供给客户的主要产品功能的增强。
2)特征版本号的增加表示产品新增了一些特征或做了一些重要修改。
3)缺陷修复版本号的增加表示在软件产品上做了一些缺陷修复工作。
当某一级版本号增加时，其下级版本号要清零。
α和β版本编号
1)在普通版本编号后面增加一个大写字符A或者B来分别表示α版本或β版本。例如1.2.4A或1.2.4B。
2)如果存在多次的α发布和β发布，可在A或B后面添加一个数字来说明发布的次数，例如：1.2.5A1，1.3.0B2。
属性版本编号
开发团队内部对版本号也有要求。
把版本的重要属性反映在版本标识中。可以包括的属性有：客户名、开发语言、开发状态、硬件平台、生成日期、技术特征、质量状态等。例如：
J2SDK.v.l.2.2:10/31/2000-18:00,native threads, jit-122
配置管理工具的自动版本编号
为了唯一识别配置库中某个配置项的某个版本，配置管理工具会自动为配置项进行版本编号，其编号规则固化在配置管理工具中。
例如常用的两级制版本编号规则：前一级标志分支，后一级标志同一分支中的特定版本，多个前后级标志串联起来可以表示任何复杂的版本。两级标志之间用“.”或“/”连接，分支的标志可能使用字母，也可能使用数字。
七、项目外资源的版本控制
除项目中所产生的源代码、文档、数据等配置项外，项目所使用的一些外部资源也应纳入版本控制。
把外部资源纳入版本控制并不意味着一定要把它们放入配置库。
以二进制形式存在的软件包一般不适合放进配置库，特别是当它很大的时候。可以保存在共享目录里，加上适当的描述说明和适当的存取权限。
在项目中，要记录清楚使用了哪些外部资源，什么版本。可以用文本文件或表格的形式记录，并放入配置库中。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
