CICO模型  

　　CICO模型主要关注的是单个文件的版本控制。图显示了一个支持CICO模型的CM系统的工作过程。用户利用库和文件系统来进行工作。文件被版本化并存储到库中，新版本的产生是由库工具控制的。然而， 文件在库中不是可以直接存取的，用户必须去检出（即Check Out）一个文件的版本到工作空间中以便读取它的内容。更改后的文件可以被检入库中（即Check in）,产生文件的一个新版本。
此模型的代表工具是SCCS和CVS。

　　组织模型

　　组织模型由CICO模型自然导出，建立于构件版本图的基础之上，同时依赖于存储库和工作空间的概念，可以通过对构件加锁进行并发控制。组织模型的重点是在CM系统支撑下加强了对创建配置、对有关的历史信息的管理和使用他们作为工作环境的支持。

　　组织模型中的配置由系统模型和版本选择规则组成。系统模型列出了组成系统的所有的构件。版本选择规则指出了组成配置的每一个构件选择版本。选择规则用于系统模型，选择构件版本，即绑定一构件到某一版本。这个模型的操作方式是：开发员根据模型的构件定义整个系统，并在每一步骤中给每个构件选择合适的版本。版本操作的工作方式如图所示。

　　CM支持主要关心的是维护系统和其构件的版本历史，并选择符合一致性配置的构件版本。只有在所选构件的版本与所选其它构件版本一致时才认为一个配置版本。

　　此模型的代表工具是CCC。

　　长事务模型

　　长事务模型主要支持包括一系列原子变更的全系统演变和由团队开发员对系统变更的协调。开发员主要操作配置而非单独的构件。事务提交的结果是新配置版本，一系列连续的变更结果生成一系列的配置版本，称为开发路径。

　　在长事务模型中，开发员主要的工作对象时配置，开发员首先选择系统配置版本，接下来把关注重点放在系统结构上。构件的版本由配置隐式决定。长事务由两个概念组成：工作空间和并发控制方案。工作空间来源于存储库或一个封闭工作空间中的一个固定配置。工作空间由工作配置和一系列已保存的配置组成。工作配置代表构件和系统结构能够被动态更改的配置。提供通过工作空间进行的透明库访问、将高效的库存储技术应用于工作空间和管理派生构件的版本。

　　此模型的代表系统是NSE。

　  变更集模型

　　主要集中于对系统配置的逻辑变更的支持。在这个模型中引入的变更集表示组成逻辑变更的对不同构件修改的集合，它是创建变更的活动完成后对逻辑变更的记录。支持这个模型的CM系统用户可以直接操作变更集。在变更集模型中，配置可描述为由基线和一组变更集组成。

　　变更传播给其它配置可通过包含各自变更集来进行。开发员使用不同的集成策略将逻辑变更集包含到一个新的系统发行中。这样的好处非常明显，例如，我们现在维护10个不同版本的产品，现在要对所有的版本修改一个缺陷（Bug）。如果相同的工具简单的重复10次显然是不可接受的。而通过变更集把这个逻辑变更从一个版本自由的传到另外一个版本。

　　开发员可跟踪逻辑变更和确定这些变更是否属于特定配置。这种配置管理的方法，因为其将重点放于逻辑变更上，所以被称作面向变更的配置管理。它不同于现在的其他3种CM模型，因为其它3种CM模型使用的面向版本的方法把重点放在构件和配置版本上。

　　在单一构件的情况下，变更集是两个文件版本之间区别的集合，通常指的是增量内容。对配置来说，变更集就是两个配置版本之间区别的集合。这组区别就是两个配置版本间的修改构件增量集合，即变更构件集的增量。
面向变更的观点不同于面向版本的观点。这有两点不同，一是逻辑变更的显式表示允许对与单个构件和配置有关的变更集进行跟踪。二是引用单个变更集并有选择地将它们纳入配置管理中的这种能力提供了对系统演化管理的支持，这种演化是基于将逻辑变更传播到维护的系统配置进行的。

　　此模型的代表工具是UCM和SABLIME。

　　结束语

　　配置管理本身无论从理论和实践都在不断丰富和发展。例如，配置管理应用于“知识库”的管理就产生了“内容管理”这一新的领域。配置管理提供的状态报告和数据统计也为软件度量提供了决策依据。配置管理为项目管理提供了各种监控项目进展的视角，为项目经理确切掌握项目进程提供了保证。配置管理也为开发人员提供了一个协作的平台，在此平台上，大家能够更有效率的交流和协作。可以说，配置管理是软件开发的基石！

　　配置管理近年来在中国得到了极大的认可，可以毫不夸张的说，没有配置管理，就谈不上软件开发，就谈不上软件质量，就谈不上软件业的发展。随着软件业规模的扩大，配置管理的实施不是要不要的问题，而是什么时间、如何实施的问题了。