配置管理工具之CVS.docxVIP

配置管理工具之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没有变化控制变化控制可以指许多事情。首先它的意思可以