10.7 在限制与非限制检出之间做选择

限制与非限制检出各自有正反两方面的理由。 而且大多只是看法不同的问题，或者同一工作用于不同类型的工作组，这里只是一些问题的概述。 组织开发团队有很多种方法。 cvs 不会强制采用某种组织结构。 它是一个可以用不同方法使用的工具。

限制检出是非常低效的。 如果两个人试图编辑一个文件的不同部分，没有理由要阻止他们那样做。 还有一种情况很常见，某人打算编辑一个文件，他检出并加锁，但后来忘记了解锁。

习惯限制检出方法的人们，他们转到非限制检出下工作时，经常抱怨冲突发生得太频繁，要解决冲突很麻烦。 而对另一些有经验的团队，冲突却很少发生，即使有也很容易解决。

出现严重的冲突非常罕见，除非两个开发者对某个设计的一段代码实现意见不一致； 而这种情况首先意味着这个开发团队人员之间没有很好地沟通。 不论在 任何 源码管理机制下，开发者必需遵循系统的概要设计； 符合这点，重叠的修改通常很容易合并。

有些情况下，非限制检出明显不适用。 如果没有被管理文件（比如字处理文件或计算机辅助设计程序编辑的文件）相应的合并工具，还有不想要合并对使用可合并数据格式的程序的改变，与其解决冲突还不如防止冲突，这时就该使用限制检出。

监视 Watches 特性可以认为是限制检出与非限制检出的中间方案。 当你打算编辑一个文件时可以先了解谁正在编辑它。这种方法要好于系统阻止多人去编辑， 它告诉你当前的状况，然后让你自己判断会不会出问题。 所以，一些开发团队可以考虑监视同时采用限制和非限制检出作为最佳解决方案。

1.12.10 以后版本的 cvs 客户端和服务器，您可以通过将 `edit -c' 和 `commit -c' 放入所有开发人员的 .cvsrc 文件打开“advisory locks”。 这样，如果其他人在编辑，cvs edit 将失败。并且，如果没有通过 cvs edit 进行注册，使用 cvs commit 也会失败。结合默认只读检出将更有效，这通过将 `cvs -r' 放在所有的 .cvsrc 中打开监测实现。