3、权限设置
创建一个代码存储库，是为了便于统一管理，但是如何让开发人员根据任务分工的不同而获得对相应配置项（源代码）的操作许可，而对于其他源代码不能操作。为此，利用Firefly提供的文件级访问权限设置，对不同目录进行用户权限设置，只有对该目录具有读写权限的用户才能对其进行操作，为子系统配置管理员授权一个文件目录，如图２权限设置图中src/ap目录授权给smq用户。
javascript:return big(this)" hspace=0 src="https://www.ltesting.net/attachments/2009/06/54376_200906290954373jVfY.gif" onload="javascript:if(this.width>498)this.style.width=498;" align=baseline border=0>
4、分支的划分
· 集成分支
为了系统集成测试需要，创建集成分支，并对该分支进行了不同子项目的权限控制，各子项目必须将开发成果纳入到该分支，凡是对纳入到该分支的配置项进行的任何变更，都必须首先从该分支获得，变更后再上传到该分支。软件的集成测试工作在这一分支中进行。项目级配置管理员拥有对该集成分支的管理和读写权限，子项目级配置管理员只有对指定的目录有读写权限。（图3分支图）
· 主干分支
主干分支对应的是整个软件开发组织的发布分支。各个子项目在现阶段的任务完成后，将可以发布的版本归并到该分支上，由该分支产生发布版本，对每次的发布基线和相关资料，以该分支上的版本为准。该分支的管理工作由项目级配置管理员负责。（图4分支及标签）
图3 分支
图4 分支及标签
上面定义的2类（分支）由配置管理员统一管理，根据各开发阶段的实际情况定制相应的版本选取规则，来保证开发活动的正常运作。
比如，软件已经发布了1.0版本，开发小组在为该软件添加新的功能，正在进行2.0版本的开发。而此时，如果Release 1.0中发现了Bug必须修正，我们就必须从Release 1.0中建立bugfix分支，进行必要的修正后，发布修正版Release 1.1，而这个版本的发布与2.0版本的开发没有直接关系。当2.0版本测试结束后，要与1.0版本中bugfix分支合并，从而发布2.0的版本。在这个并行开发过程中，创建分支和分支的合并起了非常重要的作用。
· 产品基线
当一个开发里程碑结束，或有重大事件发生时，利用配置管理系统提供的标签功能，对集成分支和主干分支进行标记，该标记作为产品基线，可以按标记进行版本发布和再现（图4分支及标签）。
· 与分支对应的本地工作区
把相关配置项纳入集中的存储库、为不同目的建立了不同分支后，按照初始设定的管理层次，子项目级配置管理员遵照“检出/检入”的工作模式对配置项进行修改，就要为每位子项目级配置管理员设定本地工作区，对所授权的目录进行的任何变更都要在本地工作区进行。
· 开发工作区
开发人员根据项目要求在自己的私有工作区中对配置项进行修改和测试活动，私有工作区可以是CVS版本控制软件工作空间或其他，自己的修改活动不会受到他人的影响，也不会影响到其他开发人员，修改和测试后的配置项提交给子系统配置管理员，由子项目级配置管理员上传到集成分支。
文章来源于领测软件测试网 https://www.ltesting.net/
