实在搞不懂受控库该怎么创建了 对基线概念不正确 ?

jesusMars

公司快进行CMMI3的评估了

可是我是一个刚刚参加工作的小鬼,我不知道该怎么样来创建"受控库"

不知道 该怎样组织,该怎么样配置,里面有什么内容!

头大了 谁能帮帮我啊    谢谢了

陈能技

首先要弄清楚受控库的概念：
受控库是相对于开发库而言的。开发库是供开发人员使用的，所有开发人员都具有读和写的权限。受控库只有配置管理员有写的权限，其他人只有读的权限，也就是说对受控库的更改必须通过配置管理员，遵循一定的变更流程，从而把配置项的变更控制起来，达到降低风险的目的。


最近也开始研究SCM了，希望获得敏捷和实用的SCM管理方法：
http://blog.csdn.net/Testing_is_believing/category/341829.aspx

leetutu

你所说的“受控库”就是配置管理系统。常用的有CVS、VVS等。开发部的配置管理系统是来管理代码等，测试部的配置管理系统通常用来管理测试计、方案、用例、自动化脚本等。在配置管理系统中，基线就是配置项在其生命周期的不同时间点上通过评审而进入正式受控的一种状态，而这个过程被称为“基线化”

zhao.nina

受控库就是个存放代码的物理工具。

云层

http://www.scmlife.com/pagetype-bbsthread-and-tid-3131.html

记得第一次在国内的坛子里看到三库的讨论的时候，登时就晕了……
三库的概念被弄得挺严重，甚至被实现为物理上的多个库……

这里，首先贴一下三库定义的原文、翻译，然后再谈谈个人的理解……

==原文位置==
（中国国家标准也有三库的定义。这里就不再给出了。这里给出的是CMMI的定义，若有其它国际上比较权威的定义，烦请熟悉的同志贴一下，谢!）

CMMI V1.0
=> level 2
=> Configuration Management
=> SG 1 Estabish Baselines
=> SP 1.2 Establish a Configuration Management System
=> Subpractices 2. Store and retrieve configuration items in the configuration management system.

==原文==

Examples of configuration management systems include the following:

Dynamic (or developer's) systems contain components currently being created or revised.
They are in the developer's workspace and are controlled by the developer.
Configuration items in a dynamic system are under version control.

Master (or controlled) systems contain current baselines and changes to them.
Configuration items in a master system are under full configuration management as described int ths process area.

Static systems contain archives of various baselines released for use.
Static systems are under full configuration management as described in this process area.

==翻译==

（感谢cmmi_cn@163.com等同志对CMMI的翻译工作！）

CMMI V1.0
=> 第二级
=> 配置管理
=> SG 1 建立基线
=> SP 1.2 建立配置管理系统
=> 子实践 2. 在配置管理系统中存取配置项

配置管理系统举例如下：

动态（或开发者）系统，包含当前正在产生或修订的组件。
它们在开发者的工作区，而且由开发者所控制。
属于动态系统的配置项，在版本控制之下。

主（或受控）系统，包含当前的基线和基线的变更。
属于主要系统的配置项，在本过程域所描述的完全的配置管理之下。

稳定的系统，包含已分发使用的各种基线的保存档。
稳定的系统，在本过程域所描述的完全的配置管理之下。


==个人理解==

首先，三库仅仅是举例，在实践中，并不是一定要弄出三个库来。
其次，三库是逻辑上的概念，在实践中，并不是要对应到物理上的三个库。
根据定义，开发库可以大致映射为开发工程师的个人工作空间，在开发工程师本机上，个人目录下。当然，对于稍大的任务，也可以映射为存储库里的一个任务分支。
而受控库，则是开发工程师相互协作、交流最新工作成果的地方。大致上，可以映射为版本控制工具（svn/cvs/cc……）的repository(存储库)。这里，可能有不同的分支/目录做不同的用途，可能会打标签、基线。
静态库，又称基线库，指的是那些重要的基线，这些基线标志着项目的重要里程碑，或者这些基线被Release（发布）给了“外界”。在比较简单的版本控制工具里，一般可以用特定标签命名规范来把它们从其他标签、基线中区别出来；在SVN中，可以设置一个特别的Tag目录。而在比较复杂的版本控制工具里，也可以用基线/标签的某种属性（质量级别）来表达。例如，当某条基线通过了系统测试后，就把它的质量级别promote（提升）到“通过系统测试”。
对于静态库，再补充一点：对于这些基线，我们通常不仅要记录源代码，最好也保存一下编译结果/安装包。这样将来用起来会比较方便。编译结果/安装包一般就不要放到版本控制工具里去了，除非你受了商业宣传的蛊惑…… 在合适的机器上建个共享目录，设置合适的权限，来存储编译结果/安装包，一般就可以了。

liucui513

谈谈我的一些看法：
    我们现在主要使用VSS来管理配置项，主要分为工作库、基线库和受控库。工作库主要是项目组成员对自己工作成果的一个保护库，可以对其进行checkin 和checkout，进行文件版本的控制，文件也不会丢失，可以对历史版本进行追溯，配置管理员会给相关人员赋予不同的权限操作，在工作库的开发类还建立了一个公共区，开发人员可以将需共享的代码放到该区内，实现代码的共享及检测。
基线库又详细分了需求基线、设计基线、编码基线、测试基线等。将通过评审的工作产品纳入相应的基线，以后的每一次更改都将进行评审，并将更改的内容（与上一版本比较）记录到文档的首页，实现版本的有效控制，不致混乱。
受控库主要是和工作库对应的，工作库里的文件项目组成员可以修改自己的文件，保护工作成果，对于受控库的文件（经过评审）可以查看，但是只有配置管理员有权限更改，其他人只有查阅的权限。通过项目变更申请流程实现文件的变更，并且是可控的。
配置管理还有待研究，毕竟自己没做配置管理员，只是针对公司目前配置管理及CMMI相关资料发表一些看法，期待其他人的精彩回答。

wyulnnhtg

受控库就是个存放代码的物理工具