5、变更集

　　Firefly将每一次工作区的检入都视作一个变更集，每一个变更集都作为项目分支的历史被保存下来，管理人员可以通过WEB界面方便的查询分支的历史。

　　6、原子事务

　　利用原子事务的概念，将一个包含多个文件改变的入库操作作为一个事务（Transaction）来对待，全部文件的提交只有成功或者不成功两种情况，没有中间状态（如一部分成功提交，而另一部分提交失败的状态）。这样能够处理一些操作过程中的异常情况，比如提交过程中网络中断等，保证软件系统的一致性，防止其他开发人员取到错误的代码而编译、运行失败。

　　7、本地记录

　　通过Delta操作支持本地版本的记录。在某一工作区中，修改了一个文件，然后通Delta操作，可以在本地记录下一个新的版本。提交到服务器上后，其他人也可以访问这一版本。

　　8、权限控制

　　Firefly采取了类似于NTFS的权限控制体系，不仅能够控制项目分支一级的权限，还可以深入到目录/文件一级进行权限设定，文件的权限缺省从目录继承，还可以手工对特定文件的权限进行调整；并且可以细分权限的等级。这种权限体系可以保证项目所涉及到的开发工作都处于受控的状态下，从而保障项目不受干扰，能够顺利开发。

　　四、建立配置管理体系

　　1、管理层次

　　依据配置管理系统功能特性，结合我们实际情况和需要，建立自己的管理体系。以往，我们已经成功地开发了其他大中型软件，但配置管理体系很不完善，一些主要配置项（源代码和程序文档）是靠手工管理，由于人员流动性大，又没有统一的配置管理体系，开发活动不能受到有效的控制，不能形成团队财富的积累。有人对配置管理是什么都不清楚，对配置管理系统的使用在思想上不容易接受，认为使用配置管理系统进行程序版本控制使开发活动受到了限制，给开发增加了工作量。特别是这次超大规模软件系统的开发，时间紧，任务重，如果配置管理系统使用不当影响项目进度或造成源程序丢失，会给开发带来巨大损失，后果不堪设想。

　　为此，从管理层次和系统集成两个方面考虑，选择了降低管理风险方案，首先采用了两层管理层次（图1 二层管理层次图）。

　　2、存储库创建

　　依据两层管理模式，配置管理和版本控制主要在项目级和子项目级配置管理员中使用。从一体化系统的结构来说，尽管该系统庞大，包括许多子系统，但是，最终要集成一个系统，而且管理模式决定了版本控制是在项目开发到一定阶段，形成初步系统模型时纳入版本控制。因此在Firefly服务器上创建一个程序代码库，用来存储初步集成的源代码。使用这样的库结构有利于对配置项的统一管理和控制，同时也能提高编译和发布的效率。

　　3、权限设置

　　创建一个代码存储库，是为了便于统一管理，但是如何让开发人员根据任务分工的不同而获得对相应配置项（源代码）的操作许可，而对于其他源代码不能操作。为此，利用Firefly提供的文件级访问权限设置，对不同目录进行用户权限设置，只有对该目录具有读写权限的用户才能对其进行操作，为子系统配置管理员授权一个文件目录，如图２权限设置图中src/ap目录授权给smq用户。

　　图2　权限配置