CVS简介

Q:什么是cvs？cvs是什么意思？

cvs是Concurrent Versions System的缩写，Concurrent有并发的，协作的，一致的等含义。CVS是一个版本控制系统，使用它，可以记录下源文件的历史 。

CVS维护的文件类型可以是文本类型也可以是二进制类型。CVS的基本工作思路是这样的：在一台服务器上建立一个源代码库，库里可以存放许多不同项目的源程序。每个用户在使用源代码库之前，首先要把源代码库里的项目文件下载到本地，然后用户可以在本地任意修改，最后用CVS命令进行提交，由CVS源代码库统一管理修改。

使用CVS的好处

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

·cvs 用一种聪明的办法把一个文件的所有版本保存在一个文件里，仅仅保存不同版本之间的差异

·cvs 最初由 Dick Grune 在 1986 年 12 月以 shell 脚本的形式发布在 comp.sources.unix 的新闻组第 6 卷里;1989 年 4 月，Brian Berliner 设计了 cvs 并编写了代码。之后 Jeff Polk 帮助 Brian 设计了 cvs 模块和销售商分支支持。

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

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

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

·你应该在 cvs 下放一个工具来支持这样一个构造系统（脚本、Makefile 等等）。

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

·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 文件 (参阅 Administrative files)。

变化控制的另一个方面指跟踪这样的情况，即对好几个文件的改变实际上只是同一个逻辑变动。如果你在一次 cvs commit 操作中检入几个文件，cvs 会忘掉它们是一起检入的，它们共用一个 LOG 信息的事实只是把它们绑在一起而已。做一个 gnu 风格的 ChangeLog 可能会有点用。 在一些系统中，变化控制的另一个方面是跟踪每个变化的状态的能力。一些变化由一个开发者写出，而另一些变化则由另一个开发者来作出评论，等等。一般来讲，用 cvs 来做，是产生一个 diff（用 cvs diff 或 diff），并且用电子邮件寄给某人，此人就可以用 patch 来应用它。这是非常灵活的，但依赖于 cvs 之外的机制以保证事情不会崩溃。

·cvs 不是自动测试程序

强制利用 commitinfo 文件测试套件应该是可能的。不过我没有听说过多少项目试图那样做或那里有微妙的陷阱。

·cvs 没有内置的处理模型

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

CVS 还有一个更加重要的特性：能记下每个文件的每次修改，以及如何被修改...对于基于 Internet 的合作方式来说，这些特性太重要了。一个地域上分散的自愿者组织显然不可能投入很多的时间来训练其成员彼此合作。因为这样的话，当该组织有成员变更的时候，为此付出的投资将损失殆尽。所以需要指定一套基本的项目分配方案，以确保新成员能较容易的适应工作，同时也需要设置一个自动的系统来接受外来代码，并使每个成员能及时得到最新修改的代码。

CVS 中会经常提到的一些术语：

Revision (修订版本)－－文件历史记录中的被开发者提交的变化。一个修订版本就是一个时常变化的项目的 snapshot (瞬态图)。

Repository (源代码库)－－CVS 存储所有修订版本历史记录的地方。每个项目都有自己的一个确定的源代码库。

Working copy (工作拷贝)－－开发者对文件作出修改时文件所在的拷贝。

Check out (检验)－－从源代码库中申请一份工作拷贝。该工作拷贝反映的是取出时项目的瞬时状态。当开发者对拷贝作出修改时，必须运用 commit (提交)和 update (更新) 命令来 “发布”变化和查看其他开发者所作的修改。

Commit (提交)－－将工作拷贝中的变化输入中央源代码库。

Log message (日志信息)－－提交修订版本的时候，附带描述变化的注解。通过查阅记录信息，人们可以获得一个当前项目进程的总结。

Update (更新)－－从源代码库中取出别人的修改数据，将其输入自己的工作拷贝，并显示自己的工作拷贝是否有未提交的修改。注意，不要和 commit (提交)混淆，更新和提交是一对互补的指令。记住: Update 将使工作拷贝和源代码库拷贝保持同步更新。

Conflicts (冲突)－－俩个开发者对同一个区域所作的变化都提交给主版本时出现的情况，在 CVS 觉察并指出这个冲突后，开发者必须解决该冲突。

www.shenmeshi.com 什么是什么，搜搜就知道！