基线的概念我基本上是明白了，就是通过了评审的一系列配置项
但是大家在项目中是怎样管理的呢?
我们公司启用了CVS版本管理服务器,平时也就管管代码
象基线中的文档之类的真不知道该如何管理
希望有经验的兄弟讲讲

真是失败，几天了竟然没有一个人回帖
难道问题太初级

我也是最近才接触到配置管理这方面，也不大懂
知道的朋友请解答下呀

你们公司就你一个配置管理员吗？呵呵，我也是新入行的，对这个还没有具体实践过，不过可以肯定的说，基线的建立是配置管理工作中很重要的一部分。
帮你顶这个帖子，呵呵。顺便一起深入的学习下，呵呵

同问

说一下个人的理解吧
如果理解了基线的定义做起来会顺手的多。
在我看来，基线就是下一步工作的基础，既然是下一步的基础，那么一定得到相关干系人的认可，所以才需要评审，通过后建立基线。
举个例子：在项目初期项目组编写了项目需求规格说明书，那么就需要得到客户的认可，看看是不是用户的需求是这样的；需要的到项目主管的认可，看看是否能够提供相关的资源实现所列出的项目需求；还需要得到项目组成员的认可，从技术的角度看看大家是不是能够实现需求规格说明书中所列出的内容。得到所有的认可后，我们就可以把项目需求规格说明书列为基线了，然后进行下一步的设计，开发等等工作。

以上是个人的一些理解，抛砖引玉吧！
可能说得有点罗嗦。

只有一个库的话，可以通过基线标签来制定基线。

对于文档，你可以定义版本升级的规则。比方X.YZ,没有基线化时候只升Z，基线化后才升Y。重大变更才升X

我们公司现在的软件文档和代码完全是分开的
只有代码使用了版本工具来管理
当然软件文档其实也有版本的概念
比如0.1,0.2...是草稿
1.0以上是正式发布
不过这些版本号都需要手工加入
这样我觉得软件文档管理起来挺麻烦
另外这些文档和代码的版本号实际上没有关联在一起的
现在我想将文档和代码纳入统一的版本管理工具
这样比如我要发布一个版本的时候
首先需要打一个tag,比如project-1_0-alpha
这时不仅仅是包含代码,而是包含该阶段下的所有软件文档及测试数据等配置项
不知道我这样做有没有什么问题?