配置管理工具之CVS

配置管理工具之CVS

这一章是为那些从没有用过CVS和那些以前可能从没用过版本控制软件的人所准备的。

如果你已对CVS很熟悉，仅仅想了解某一个特点或是为了记住某一个命令，那么你可以跨过这一切。

CVS是什么?

CVS是一个版本控制系统。使用它，你可以记录下你的源文件的历史。

例如：修改软件时可能会产生一些bug，而且可能过了很久你才会察觉到它们的存在。有了CVS，你可以很容易地恢复旧版本，并从中看出到底是哪个修改导致了这个bug 。有时这是很有用的。

当然了，你可能把所有版本的所有文件都保存了下来。但这会浪费大量的磁盘空间。而CVS用一种聪明的办法来保存一个文件的所有版本——仅仅保存不同版本之间的区别——在一个文件里。

如果你是项目开发组的一员，CVS也会帮助你。除非极为小心，成员之间很容易互相覆盖文件。一些编辑器，如GNU Emacs,会保证同一时间内同一文件绝不会被两个人修改。不幸的是，如果有人用了另外的编辑器，这种保护就没用了。CVS 用隔离开不同的开发者解决了这个问题。每个开发者在他自己的目录里工作，等每一个开发者都完成了他们自己的工作后，CVS会将它们合并到一起。

CVS最初由Dick Grune在1986年12月以shell scripts的形式发布在comp.sources.unix的新闻组第6卷里。虽然当前的CVS中没什么代码来自于这些shell scripts,但许多CVS的冲突解决算法是从它们来的。

1989年4月，Brian Berliner设计了CVS并编写了代码，之后Jeff Polk帮助Brian设计了CVS模块发行分支。

你可以从好多渠道得到CVS，包括从INTERNET上自由下载。有关下载CVS和其它与CVS相关的话题，请访问下面网址：

/

http://www.loria.fr/~molli/cvs-index.html

有一个关于CVS的邮件列表，名叫info-cvs,要订阅或退订请发email:

info-cvs-request@。如果你更喜欢新闻组，comp.software.config-mgmt 可能比较适合于讨论CVS（还有其它一些配置管理系统）。将来，可能会创立一个comp.software.config-mgmt.cvs, 当然那要确取决于在

comp.software.config-mgmt上有足够的CVS讨论。

你也能订阅bug-cvs邮件列表,详见[附录 H]。要订阅可以发emal到

bug-cvs-request@。

CVS不是什么？

CVS可以为你做很多，但不要指望它能为每一个人做每一件事情。

CVS不是一个BUILD系统。

虽然你的源码库(repository)和模块文件与你的BUILD系统互相作用(例如：Makefiles)，但它们本质上还是互相独立的。

CVS不能指导你如何构造什么，它只是将你所设计的文件以一种树结构保存下来以备恢复之用。

CVS不能决定如何在一个检出的目录使用磁盘空间。如果你在每一个目录中都写下Makefiles或脚本，且必须知道其它一切的相对位置，有时不得不要检出整个源码库。

如果你将你的工作模块化，并且建立了一个共享文件的build系统（通过links，mounts,Makefiles里的VPATH等)，你就可以随意安排磁盘的使用。

不过你要记住构建和维护这样一个系统是要做许多工作的，而CVS不善此道。

当然了，你应该在CVS下放一个工具来支持这样一个构造系统（脚本，Makefiles,等等）。

当有些变化发生在CVS范围之外时，要想想什么文件需要重建。一个传统的方法是用make来构造，并用一些自动化的工具来产生make所用的相关文件。

关于结合CVS进行build，请参考[第 14 章]。

CVS不能替代管理.

你的经理和项目负责人应经常与你交流以确保你时时记得进度表、合并点、分支名和发布日期。如果他们不这样做，CVS也没用。

CVS只是一个用来使你的资源与你的步调一致的工具。但你是风笛手和作曲家。没有哪种乐器会自己演奏或是作曲。

CVS 不能代替开发者之间的交流.

在单个文件内遇到冲突时，大多数开发者不费多大力气就能解决它们。但更常见

的"冲突(conflict)"，是那些难度较大、不在开发者之间进行交流就没法解决的问题。

当在一个文件内或多个文件中同时发生变化时，CVS并不知道何时它们会在逻辑上发生冲突。它的冲突(conflict)概念是纯粹文本意义上的，这种冲突会在同一个文件的两种变化十分接近以致于会破坏合并命令(如diff3)。

CVS决不会指出程序逻辑上非文本或分布式的冲突。

例如：假如你在文件A中改变了函数X的参数。同时，别人在编辑文件B，仍用旧参数调用X这个函数。此时产生的冲突CVS可就无能为力了。

要养成经常阅读说明书和经常与你的同伴交谈的习惯。

CVS没有变化控制

变化控制可以指许多事情。首先它的意思可以是BUG跟踪(bug-tracking)，就是说它能维持一个数据库,其中包括已报告的BUG和每一个BUG状态（比如：是否已更正？在哪一个版本中？提交这个BUG的人是否认为已经更正？）。为了使CVS和一个外部的跟踪BUG系统协调一致，请参考rcsinfo和verifymsg文档[附录 C]。

变化控制的另一个方面指跟踪这样的情况，即对好几个文件的改变实际上只是同一个逻辑变动。如果你在一次cvs commit操作中改变了几个文件，CVS会忘掉它们是一起改变的，即便它们共用一个LOG信息。做一个GNU风格的Changelog 可能会有点用。

在一些系统中,变化控制的另一个方面是跟踪每一个变化的状态的能力。一些变化由一个开发者写出，而另一些变化则由另一个开发者来作出评论，等等。一般来讲，用CVS来做,是产生一个diff（用cvs diff或diff）,可以用patch来利用。这个非常灵活，但依赖于CVS之外的机理以保证事情不会崩溃。

CVS不是自动测试程序

测试套件可以利用commitinfo文件。不过我没有听说过多少项目试图那样做或whether there are subtle gotchas。

CVS没有内建的处理模型

有些系统提供一些方法确保变更或发布通过不同的步骤,以及各种所需的批准过程。一般地，你可以用CVS来完成它，但是有点不太够。有些情况下你想用commitinfo, loginfo, rcsinfo或verifymsg文件，要求在CVS提交之前完成某些操作。你也会考虑诸如branches和tags等特性是否能用在一个开发树，然后合并仅被证明一次的修改到一个稳定的树。