CVS可以为你做很多，但不要指望它能为每一个人做每一件事情。
虽然你的源码库(repository)和模块文件与你的BUILD系统互相作用(例如：Makefiles)，但它们本质上还是互相独立的。
CVS不能指导你如何构造什么，它只是将你所设计的文件以一种树结构保存下来以备恢复之用。
CVS不能决定如何在一个检出的目录使用磁盘空间。如果你在每一个目录中都写下Makefiles或脚本，且必须知道其它一切的相对位置，有时不得不要检出整个源码库。
如果你将你的工作模块化，并且建立了一个共享文件的build系统（通过links，mounts,Makefiles里的VPATH等)，你就可以随意安排磁盘的使用。
不过你要记住构建和维护这样一个系统是要做许多工作的，而CVS不善此道。
当然了，你应该在CVS下放一个工具来支持这样一个构造系统（脚本，Makefiles,等等）。
当有些变化发生在CVS范围之外时，要想想什么文件需要重建。一个传统的方法是用make来构造，并用一些自动化的工具来产生make所用的相关文件。
关于结合CVS进行build，请参考[第 14 章]。
你的经理和项目负责人应经常与你交流以确保你时时记得进度表、合并点、分支名和发布日期。如果他们不这样做，CVS也没用。
CVS只是一个用来使你的资源与你的步调一致的工具。但你是风笛手和作曲家。没有哪种乐器会自己演奏或是作曲。
在单个文件内遇到冲突时，大多数开发者不费多大力气就能解决它们。但更常见的"冲突(conflict)"，是那些难度较大、不在开发者之间进行交流就没法解决的问题。
当在一个文件内或多个文件中同时发生变化时，CVS并不知道何时它们会在逻辑上发生冲突。它的冲突(conflict)概念是纯粹文本意义上的，这种冲突会在同一个文件的两种变化十分接近以致于会破坏合并命令(如diff3)。
CVS决不会指出程序逻辑上非文本或分布式的冲突。
例如：假如你在文件A中改变了函数X的参数。同时，别人在编辑文件B，仍用旧参数调用X这个函数。此时产生的冲突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之外的机理以保证事情不会崩溃。
测试套件可以利用commitinfo文件。不过我没有听说过多少项目试图那样做或whether there are subtle gotchas。
有些系统提供一些方法确保变更或发布通过不同的步骤,以及各种所需的批准过程。一般地，你可以用CVS来完成它，但是有点不太够。有些情况下你想用commitinfo, loginfo, rcsinfo或verifymsg文件，要求在CVS提交之前完成某些操作。你也会考虑诸如branches和tags等特性是否能用在一个开发树，然后合并仅被证明一次的修改到一个稳定的树。