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 (提交)－－将工作拷贝中的变化输入中央源代码库
