3、基本的配置管理功能
图7.2是SCM代码管理工作的总结。初始产品层稳定之后，就建立了第一条基线。随着持续的增强，就会伴随每一步开发建立一条新的基线。每条基线及所有相关的变更将保存在一个永久数据库中。这样，基线就成为包含最新版本的正式的产品仓库。对基线要进行全面的保护，只有经过测试的代码和已批准的变更才能放入基线中。基线是用以确保所有软件开发人员的工作一致的正式资源。
SCM的关键任务是：
● 配置控制
● 变更管理
● 修订
● 版本
● 差异代码
● 条件代码
3.1 配置控制
配置控制任务是围绕代码的正式版本展开的。保护系统修订的最简单的方法是，为不同层次的系统修订分别保存一个正式程序的副本。虽然这样可能增加很多存储工作，但是最严重的问题常常和代码分歧有关。当两个或更多的组使用公共代码的相近版本甚至同一版本的不同副本进行工作时，对于同一个问题，他们经常采用不同的解决方法。通过考察系统驱动，即可知道这样做的最终成本很高。例如，一个程序员可能需要系统控制程序的一个副本来进行单元测试。虽然系统控制程序没有完工，但程序员需要的功能已经可用。直接向开发人员提供这样一个未完工的副本比花费大量时间编写一个类似的测试程序要明智得多。在测试中，如果程序员在控制程序驱动中发现了一个问题，则可能要对X进行修复，以便继续测试活动。同时，其他程序员在对其他驱动程序和控制程序进行测试的过程中，为了解决同样的问题可能要对Y进行修复。
由于对同样的代码可能进行多种不同的变更，因此相互协调就成了一个重要的问题。除非所有的驱动程序都定期从同一个基线产生，否则每次测试都会因其他变更而失效。经验表明，没有任何两个独立的程序副本可以永远保持一致。如果确实需要分别保存副本，则从一开始就应当把它们区分开来，当作不同的版本对待，即使它们一开始完全一致，也会很快产生差别。
解决这类问题的可行方案是，对于很多组都要使用的公共代码，只保持一个正式的版本。可以偶尔使用工作副本，但是所有这些公共代码必须以一个公共库作为正式的来源，而且只有经过正式批准的变更才能加入到该库中，然后，可以通过一个标识要包括的所有代码的驱动程序内容表构造驱动程序。
在这样一个库的支持下，程序员可以确信他们使用的控制程序驱动是最新的版本。此外，如果在测试中遇到问题，就可以将这些问题传递给控制程序开发人员，以便在正式库中进行修复。如果完成测试需要临时驱动程序补丁，那么，只须修复和存储一次正式程序版本。
3.2 修订
对修订活动进行跟踪是配置管理的一项重要任务。在大型系统中，某些程序如控制程序，为所有其他程序提供了基本的功能。当一个组件中的模块集成为一个可测试的单元时，就要按照最新的控制程序层次对它进行测试。发现新问题时，要重复以前的测试，以找到问题的根源。如果使用最新版本的控制程序模块重新开发早期的驱动程序，由于这些模块之间可能存在差别，因此原来的测试不能准确地重复进行。解决的方法就是跟踪每个模块和测试用例的每一次变更。只有一个最新的正式版本，所有历史版本都进行了标识和保存。这些旧版本可以为跟踪问题提供帮助。
开发工作是修订、集成和测试的循环往复。为了跟踪每个项目的修订历史，对每个测试、模块、组件、产品和系统，必须分别用不同的数字进行区别。比如，对于经过多次修订的MEM模块，我们把1989年第一次修订的版本标记为MEM8901，第二次修订的版本标记为MEM8902.每个模块的每次修订都进行惟一性标识，这样就可以在需要时检索到。更进一步，模块MEM的测试人员可以从MEM8901开始，逐步检查，以确定问题最早发生在哪里。识别出MEM模块在某点的变更之后，将其和预期的功能进行比较，就可以找出存在的问题。
