控制
所有 SCM 系统的一个主要角色就是帮助管理开发生命周期中的变更。系统必须在对项目的总体工作流进行适当的控制和不对个体项目成员施加令人不快的限制之间做出权衡。
目前开发人员通常位于不同的办公室、不同的国家，不同的时区。试图将各个开发团队的工作集成起来需要一个能够控制以下东西的系统：
. 谁在致力于变更请求。
. 变更如何从开发流向集成。
. 谁可以使用特定的开发流。
另一方面，SCM 解决方案需要足够灵活，以便允许整个团队使用的是相同的代码，或者允许个别团队成员使用"专用"的代码分支。当需要 专用分支时，系统就需要能够控制那些专用分支和项目集成区域之间的变更流。
目前软件的复用很重要，因为它可以降低成本。因此，如果能够实现一种"食物链"的开发方法其价值不可估量。这种方法是开发团队何时生成打算被该项目的其他团队使用的可交付工件。这样的组件应该只能被它的制造者更改。
如果正确理解和实现，这些特性能创建一个受控的开发环境，从而使开发人员的工具更具生产力，并且生成更具预测性的项目日程安排。
业务价值：
软件复用对于降低成本很重要。你需要设置实现这个目标以及其他目标的策略。该上下文中的控制是关于计划如何工作以及建立这些规则的适当实施。有多少伟大的成功是在没有计划、过程或者路标的情况下获得的呢？不是很多。
控制看上去是一个缓慢的过程，但是它创建了更好实现指定结果的顺序。它与决定行人走人行道类似。如果我们都同意行人走人行道，卡车走机动车道，那么我们就不会被卡车撞。这种计划和控制就是很好的业务。
可审计性
开发软件是一个迭代的复杂过程，需要能理解发生的所有事情的敏锐眼光。它与我们对落地大座钟的感觉类似。从外面看，指针移动，闹钟报时，你就能知道时间。但是在内部，存在着连续的移动。齿轮啮合，按照不同的速率转动。特殊的齿轮经过校正，可以精确到毫秒。所有部件协调起来实现了绝对精确--从外部看来如此简单的和谐。
软件与此类似，除了一点不同--它本质上要复杂的多。并且在所有的活动中，你有时必须问个究竟。
这就是可审计性存在的理由。可审计性指的是在任何时候询问关于软件发布的特定版本或配置的谁、什么、何时和何地问题的能力。它还必须能够强调版本之间的区别。构建工程师、经理和开发人员必须随时回答诸如下面的常见查询：
. 组件 foo.y 根据最新需求更改了吗？
. 谁对 3.2.4 版的第 10249 行做了变更？
. 在修订版中所有迫切的 bug 都得到了修复吗，以及谁将它们登入？
答案对于平稳解决像构建脚本或包含文件中的错误至关重要。手工查找信息消耗宝贵的时间。确实，因为不能向 SCM 系统询问这些关键信 息而感到气馁的开发人员可能只是让构建和测试团队挑选出东西--从而浪费了更多的时间，并极大地降低了项目效率。
业务价值：
可审计性需要 SCM 系统跟踪和记录有关变更的元数据（关于数据的数据）。很重要的是，它还允许你查询数据库，以轻松找到答案。可审计性可将寻找答案的时间从数天减少到数秒。假定每天六个问题，乘以每个问题节省的时间，你就会意识到这将带来多么大的业务价值啊！
可复制性
在项目过程中发生的很多变更中，并不是所有的都比原来好。有时候，前面的版本比后面的要好。你必须能够快速复制出前面的配置，以便恢复到项目的之前状态。
可复制性就像是航拍一样。它代表了截然不同的时间，以及项目详细、广泛的视图。
软件开发上下文中的可复制性需要：
. 复制整个开发环境的配置的能力，包括项目生命周期中任何阶段的工具、测试和文档。这很关键，但是从这方面来说很少有产品能完全做到这一点。
. 不但自动重新创建构建中使用的文件，还能自动创建目录结构和整个名称空间的能力。
通常，更早版本的目录结构被识别--文件或子目录名称发生改变，大型目录被分割成更小的目录，并且文件被移动。重新创建早期版本目录结构的能力被称为名字空间版本化。SCM 必须为名字空间版本化提供一种机制，而不只是为文件版本化提供。
比如，它对于将代码基及时回退到不是特别显眼但是体现了更好的代码版本的时刻很有用。回退需要可复制性。根据回退作用域的不同，它可能需要只有名字空间版本化才能提供的大量细节。
业务价值：
将项目回退到一个里程碑或者任意时刻方面的可复制性可能只产生周期性的价值。但是当例行使用以保证正在构建的同时已经过测试时，它在降低风险方面的价值不可估量。
可复制性类似于版本控制--允许你在一个构建中复制精确的文件版本和每个文件的配置。花费项目组数天或数周时间重新构建的东西可能在几秒内发生。
