这 个图谱没有显示所有的概念，没有说的概念包括：组件演进的粒度（例如从版本识别到配置识别，再到配置的版本）；系统模型的进展（例如从命令文件到make 文件，再到作为版本化对象的系统模型）；识别不同角色和不同类型的变更（例如缺陷对增强对紧急补丁）；和当前的研究工作。
考虑到是从CM系统 概念的抽象，与实现相比本文中的描述是简化的，只是要发现一些共同概念，但对这些概念确实没有共同的术语。概念和其实现的区别并不是很清楚，例如，工作区 的实现在不同CM系统中并不相同，因而为用户提供了不同的功能。因此，这些概念一定要是所有实现的最低共同点吗？因为事务包含了工作区和透明视图，那么工 作区，透明视图和事务就真的是一个概念吗？或者它们是三个概念，就像图上显示的？
抽取CM概念的另一个困难是过载的概念，也就是概念有太多的 目的（这些目的在CM系统中并不统一），例如，图谱中的Rational子系统概念支持限制变更的范围，尽管子系统提供了更多的功能，它可以：提供名称范 围边界，对工作区来说则代表了工作在一个团队的不同配置或同样配置，提供了接口检查或者代表了一个不易变和可执行组件（Rational术语的"load view"）。所以，为了讨论子系统，有必要专著于某个特定的方面，因此，过载造成了抽取基本概念的难度，类似的，概念的组合部分，或者是某个概念特定实 现的副作用，让概念的抽象更是充满技巧。例如，考虑一个变更请求，生命周期的角色（例如配置经理和测试经理）和阶段（开发和测试）是否对其至关重要，还是 毫不相关？
在任何等级，概念的图谱提供了开发的开始点，或至少抽取一个CM模型－－一组基础CM服务－－从存在的CM系统。此外需要许多检验工作：图谱的用处，是否有其他概念，如何定义，命名和展示概念及其它语义，如何组合概念到一个有用的CM系统。