clearcaselt配置

bmccbj

201
b)、两个或两个以上的用户对同一文件的不同部分进行修改的情
况
这种情况就是如用户A与用户B都checkout了文件example.h，内容
如下：
int callby (int count)
{
printf("ExcelStor!\n";
}
void main(int argv,char *argc)
{
//added by my cvs
printf("I am Cather\n";
}
int mainexample()
{
printf("OK\n";
}
然后用户A修改成如下，并提交到CVS服务器（一般将正常提交）：
int callby (int count)
{//add
printf("ExcelStor!\n";
}
void main(int argv,char *argc)
{

bmccbj

202
//added by my cvs
printf("I am Cather\n";
}
int mainexample()
{//add
printf("OK\n";
}
接着用户B修改成如下：
int callby (int count)
{//add
printf("ExcelStor!\n";
}
void main(int argv,char *argc)
{
//modified
printf("I am Cather\n";
}
int mainexample()
{//add
printf("OK\n";
}
当用户B选择“Commit Selection”时将提示：
cvs server: Up-to-date check failed for `example.h'
cvs [server aborted]: correct above errors first!

bmccbj

203
此时表明已经有用户对同一个文件example.h进行修改并提交到
CVS服务器，这时
要先选择“Update Selection”对本地example.h与CVS服务器上的
example.h文件进行
同步与合并，不用选中出现的任何选项，直接选择“OK”，这时将
显示如下：
cvs -z9 update example.h (in directory C:\my cvs\STW\src\)
RCS file: /home/cvsroot/STW/src/example.h,v
retrieving revision 1.5
retrieving revision 1.6
Merging differences between 1.5 and 1.6 into example.h
M example.h
***** CVS exited normally with code 0 *****
表明用户B与用户A的修改已经合并成功，同时文件example.h
的图标也将变成红色，合并后的文件是存放在用户B的本地机上，为了
更新到CVS服务器还必须选中example.h并右击选择“Commit
Selection”才能把用户A与用户B的修改合并后的结果提交到CVS服务
器上。注：M表示此文件已经被修改过。
c)、两个或两个以上的用户对同一个文件的相同部分进行修改的
情况
这种情况就是如用户A与用户B都下载了文件example.h，内容
如下：
void main(int argv,char *argc)

bmccbj

204
{
printf("I am Cather\n";
}
然后用户A把文件修改成如下，并提交到CVS服务器（一般将正常提
交）：
void main(int argv,char *argc)
{
printf("I am Cather\n";
printf("I am Pat\n";
}
接着用户B又把文件修改成如下：
void main(int argv,char *argc)
{
printf("I am Cather\n";
printf("I love you Cather\n";
}
如果用户B这时选择“Commit Selection”准备把修改结果提交到
CVS服务器，此
时将显示如下的错误提示：
cvs -z9 commit -m "update in 11:20" example.h (in directory
C:\my cvs\STW\src\)
cvs server: Up-to-date check failed for `example.h'
cvs [server aborted]: correct above errors first!

bmccbj

205
***** CVS exited normally with code 1 *****
表明用户B的修改与其它用户的修改冲突，这时要先选择“Update
Selection”，将显示如下提示：
cvs -z9 update example.h (in directory C:\my cvs\STW\src\)
RCS file: /home/cvsroot/STW/src/example.h,v
retrieving revision 1.9
retrieving revision 1.10
Merging differences between 1.9 and 1.10 into example.h
rcsmerge: warning: conflicts during merge
cvs server: conflicts found in example.h
C example.h
***** CVS exited normally with code 0 *****
example.h前面的C表示与其它用户的修改有冲突，并且文件的图
标会加显示一个“C”，如下所示：
双击example.h将显示example.h的内容，如下：
void main(int argv,char *argc)
{
printf("I am Yanxi\n";
printf("I am Cather\n";
<<<<<<< example.h
printf("I love you Yanxi,too!\n"; //这部分为你的修改
=======

bmccbj

206
printf("I love you Cather!\n"; //这部分为其它用户的修
改
>>>>>>> 1.10
}
这时你应该与用户A进行协商以决定最终要怎样修改。比如，可以
修改成：
void main(int argv,char *argc)
{
printf("I am Yanxi\n";
printf("I am Cather\n";
printf("I love you Yanxi,too!\n"; //这部分为你的修改
printf("I love you Cather!\n"; //这部分为其它用户的修
改
}
然后选择“Commit Selection”进行提交，将显示如下的提示信息：
cvs -z9 commit -m "update in 11:20" example.h (in directory
C:\my cvs\STW\src\)
Checking in example.h;
/home/cvsroot/STW/src/example.h,v <-- example.h
new revision: 1.11; previous revision: 1.10
done
***** CVS exited normally with code 0 *****
表明用户A与用户的修改已经合并成功。

bmccbj

207
这样，向CVS服务器提交文件所会遇到的问题也基本上就是这些，
用户要根据所遇到的实际问题进行修改。
7、向CVS 服务器添加新文件
在本地添加文件后，要提交到服务端。先选中文件，然后点击
“添加按钮”，添加文件后，再在右键菜单中选择提交命令“Commit
Selection”即可。
如图，选中文件example.h.bak，因为example.h.bak当前不是
CVS的文件，此时“添加按钮”将由不可选状态变成可选状态，所以
Status中显示为“NonCvs file”，选择“添加按钮”之后
example.h.bak图标将变成红色并增加了一个A字母，如下：
然后选中example.h.bak，右击，选择“Commit Selection”
把文件example.h.bak提交到CVS服务器上而成为CVS的一个文件。
8、结束语
读了本段，你基本上已经能为自己或公司配置一个实用的CVS服务
器与WinCVS客户端，配合使用CVS进行系统开发或其它文档的版本管理
与控制

bmccbj

208
第二部分 相关资源
第一章 一些相关概念
1 基线的理解
“基线”是一个很常见的术语，在配置管理和项目管理里面都能看到，
而且还有很多衍生的术语，例如基线提升、基线化、基线审计，等等。
我个人以前对微软的那套开发流程（就是product cycle model）
以及PSP、TSP了解比较多一些，这些流程里面对“基线”的概念提的不多。
但 接触RUP、MSF以及项目管理以后，看到到处都有baseline，就觉得
迷惑了。
经过我自己的理解，以及和几个同事的讨论，现在我觉得我们通常
看到的“基线”这个术语有两个意思：
1）代表多个源代码文件的一组版本。
比如有三个文件，aaa.c、bbb.c和ccc.h。可以对这三个文件做一
个基线，取aaa.c的版本1.1，取bbb.c的版本1.3，取ccc.h的版本1.0。
(1.1,1 .3,1.0)就是一个基线。换句话说，通常在vss和cvs里面做label，
就是在做基线。
这种基线对“构建审计”特别有用：在做build的时候，可以先对所有
源文件做一个label，取名为"Build2394"，然后再编译、集成。这样，
以 后如果要找到和build 2394对应的原文件，只需要到vss或者cvs里
面把所有文件对应label Build2394的版本取回来就可以了。
2）代表文档的一个稳定状态。

bmccbj

209
比如有一个项目设计文档，当设计基本完成，开发即将开始的时候，
需要把这个文档固定下来，内容不能再频繁改变，否则开发人员就无所
适 从了，可能导致每个人所参照的文档并不是同一个文档。用一句上
海这里的生活用语来说，就叫做要把这个文档“敲定”。
一个文档如果经过讨论被通过了，被固定了，就可以说这个文档被
“基线化”了，然后所有人就可以在这个“基线”的基础上工作。
当然，文档不可能一成不变，所以当对文档的修改仍然会不断进行，
但这种修改并不会随时随地的添加到被“基线化”了的文档中去。因为既
然是“基线”，就不能随便动。
但是到了一定时候，修改积累到一定程度，就需要把很多修改合并
到原来的文档中去了，并生成一个新版本的文档作为团队中所有的人的
参考 标准，并把老的版本淘汰掉。这就叫做“基线提升”。
合同基线
当你和客户讨论后，“敲定”的合同
4）发行基线
你会对你要发行的代码，文档版本进行label, 比如
Release2.2,
这样，你可以随时取出此版本作build，进行测试，发布。
5）产品基线
当发布时，你会对产品中所有的配置项进行label,包括可执行
命令，文档手册，库文件。。。
基线是与里程碑相对应的，所以每个里程碑处建立一条基线；
但变更同样属于配置管理的范畴，所以配置项变更后也应建立基
线。

bmccbj

210
但是如果配置项的变更很微小，就没有必要再建一条基线了。
2 配置状态报告及申计
配置状态报告：
提供配置项的状态信息，以反映项目的进展情况，同时可以从中根据配
置项的操作记录对开发团队的工作关系作一定的分析。
-报告应定期进行
-使用CASE工具生成，保证客观性
主要内容：
变更请求列表
基线库状态
Release信息
备份信息
SCM工具状态
其它应予以报告的事项
配置审计：
验证配置项信息与配置标识（需求、标准、流程…）的一致性
功能配置审计(FCA,Functional Configuration Audit)
物理配置审计(PCA,Physical Configuration Audit)
1.配置审计-What
FCA:验证配置项的功能特性与需求（原始需求、变更请求… ）的一致性
PCA:验证配置项的物理特性与期望（命名标准、变更流程… ）的一致性
2.配置审计-Why
预防提交错误的产品