1.2 CVS 不是什么？

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

cvs 不是一个 BUILD 系统。

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

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

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

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

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

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

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

关于结合cvs进行 build，请参考Builds。

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 等特性是否能用在一个开发树中执行任务，然后仅当它们被证实就把某些修改合并到一棵稳定的树中。