我不大赞同楼主对受控库的理解。楼主提到：“而受控库，则是开发工程师相互协作、交流最新工作成果的地方。”
我认为开发工程师相互协作、交流最新工作成果的地方恰恰是开发库（动态库）的概念。
而每个开发工程师自己的开发环境（本机）只是属于开发库的一部分。
能够提供所有开发人员协同工作的才是开发库。
受控库应该是有严格权限控制的库别，能够提交到这个库中的文档或者代码的角色应该是受限制的，而不是开放的。
这个库，同时也是开发组和测试协同工作的一个库别，要提交给测试组测试的代码和测试依据的文档都应该是从这个库别中发出的。
我觉得如果只有一个库的话，我使用过的配置管理工具（vss/cvs/svn）都不能很好地解决软件受控的处理。
配置管理员存取配置项得到受控库的工作我觉得单单用基线或者标签来实现的话，还是很困难的。
但是受控库和静态库倒是可以用用基线或者标签来区分的。因为这2个库都是相对稳定的库别。
3库可以用2库来实现倒是比较好理解一点。

[ 本帖最后由 SnowJin 于 2007-7-23 17:06 编辑 ]

引用:

原帖由 SnowJin 于 2007-7-23 16:49 发表
我不大赞同楼主对受控库的理解。楼主提到：“而受控库，则是开发工程师相互协作、交流最新工作成果的地方。”
我认为开发工程师相互协作、交流最新工作成果的地方恰恰是开发库（动态库）的概念。
而每个开发工 ...

很赞赏SnowJin的坦诚！我们需要这样的气氛，才能互相学习，共同进步！

我又翻看了一下英文原文，关于动态库，
Dynamic (or developer's) systems ... are in the developer's workspace and are controlled by the developer.
注意到workspace和developer用的都是单数。这么说，特定的动态库，是给特定的某一个开发者使用的。
这与SnowJin的理解不同。

而对于受控库，我则不确定当年的理解是否准确。
Master (or controlled) systems contain current baselines and changes to them.
注意到，这里不仅包含当前活跃/比较新的基线，也包括对基线的变更。
但是，这里所提的变更，是指的什么质量程度的变更呢？
如果，只要是程序员提交的，就算，那么，受控库就是开发工程师相互协作、交流最新工作成果的地方，如我当年的理解。
如果，只有通过集成的，通过测试的，才算，那么，受控库的内容，就是相对稳定的，相对正式的内容。这样，就和SnowJin和shuku的观点一致。

另外要提及的是，
三库的概念，是 Examples of configuration management systems，是些示例。
所以，在实际操作中，不必太拘泥于这套概念。重要的是理解它背后的观点：
不同的内容，用相应的合适的方法存储和控制；
适当隔离，物理上或逻辑上，以避免混乱和误操作。

第三个库我们一般称为产品库，是存放已冻结、供交付的基线的地方

非常感谢流水先生的讲解，之前只是了解到配置管理中有开发库、基线库、产品库的概念，在工作过程中并没有去深入理解三库的具体含义。当时读文档的时候总是想把他们对应到物理库上，没有想过其实它们应该是逻辑上的三库，这样就容易理解多了。
开发库对应的是开发人员的个人工作空间；
受控库对应的是用配置管理工具管理的配置库；
静态库是不是应该对应到产品库；

正迷惑着呢  谢谢

不错，我正想学习呢

我们一直是开发库\受控库(基线库)\产品库三库定义的,三库是逻辑上的三库,根据权限进行三库控制.
开发库大致映射为开发工程师的个人工作空间，在开发工程师本机上，个人目录下。此库开发人员有可写权限.
受控库就是经过评审或测试的工作产品,进入基线,不允许随便更改.此库开发人员只有可读权限.
产品库就是最后开发结束后形成的工作产品库.此库开发人员没有任何权限.

个人理解,!

很受用，多谢大家的分享．小弟刚刚接触ＣＭＭ，以后还请多多指点．谢谢

三库概念在一个库里通过分支、基线实现应该是没有问题的。如果确实觉得有必要分开的话，静态库（产品库）单独建立物理上的库似乎可行，因为产品库存放的基本都是一些稳定的版本，相反在受控库中生成太多的基线可能不便于管理，所以我觉得是不是可以把产品库单独管理而把三库变成两库

比较赞同楼上的，三库是概念上的三库，物理上可以为一个库或者两个库，即把产品库单独作为一个库，因为这个库处于冻结阶段，只有特殊的人员才能访问。