章 10. 多人开发

目录
文件状态
更新文件
冲突示例
提交后通知其他人
多人同时运行CVS
跟踪文件编辑
在限制与非限制检出之间做选择

当软件项目不再由一个人来开发的时候,事情总会变得复杂起来。因为经常会碰到两个人同时编辑一份文件的情况发生。有一种解决方案,文件加锁(file locking)或者节制检出(reserved checkouts),就是每份文件每次只允许一个人来编辑。这种方法在很多版本控制软件中使用,比如rcs和sccs。在CVS中可以用cvs admin -l命令来做到节制检出[admin options 在 附录 A]。这点在cvs里不如观察(watch)特性做的好,后文有述,但对于寻找“节制检出”手段的人来说也够用。还可以通过观察与合理过程(而非用软件禁止)来避免俩人同时编辑同一文件。

cvs默认的方式为无限制检出(unreserved checkouts)。这种方法下,多个开发人员可以同时编辑自己的工作拷贝(working copy)。第一个提交的人做的修改无法自动通知到其他修改此文件的人,其他人只有在提交此文件的时候才得到错误信息。他们要从源码库将自己的工作拷贝更新,这一过程可以自动完成。

cvs还支援各种便利的沟通方式,而不是像节制检出那样用强制的规则。

下面的章节将解释这些工作模式,和一些相关的问题。

文件状态

依据你对检出文件的操作和其他人对源码库文件的操作,可以将文件分成各种状态。这些状态可以用status命令看到:

Up-to-date

该文件与该分支在源码库里面的最新版本文件内容一致。

Locally Modified

你修改了文件,并且还没有提交。

Locally Added

你用add命令添加了该文件,但没有完成提交。

Locally Removed

你用remove命令删除了该文件,但没有完成提交。

Needs Checkout

另有人做了提交,在源码库里面有了新版本。这个名字有些误导,你应该用update而不是checkout来得到最新的版本。

Needs Patch

与Needs Checkout类似,但cvs服务器只发送补丁(patch)而不是整个文件。发补丁和发整个文件做的是同样的事情。

Needs Merge

你修改了这个文件,同时其他人也做了修改并已经提交到了源码库。

File had conflicts on merge

类似于Locally Modified,只是因为用命令造成了冲突。你要解决这个冲突,参阅[冲突示例]。

Unknown

cvs不能识别该文件。比如你创建了一个新文件,但还没有执行add命令。

为了说清文件的状态,status命令还报告工作目录中文件的Working revision,它是该文件编辑前的版本,和一个Repository revision,它是该文件在源码库里面的最新版本。

status命令的选项列于[附录 B]。了解Sticky tagSticky date信息,参看[粘性的标签(Sticky tags) 在 第 4 章]。了解Sticky options参看[update options 在 附录 A]中-k选项。

你可以认为statusupdate命令有互补性。用update将文件更新,而用status可以得到update能做些什么的提示(当然,源码库的状态可能会在用命令时有所改变)。其实,要得到比status命令更简洁的信息,可以使用

$ cvs -n -q update

选项是要求不做实质更新,仅仅显示状态信息;而选项用来避免打印每个目录名。了解update命令的更多信息,查阅[附录 B]。