MyEclipse 中cvs详解
版本管理系统可以帮助开发人员有效地管理软件资源的版本问题。CVS（Concurrent Version System）是目前最常用的版本管理系统，而 ECLIPSE 是最流行的开放源码的集成开发环境。在 ECLIPSE 中，与 CVS 相关的功能被统称为
小组开发环境。本系列的第 1 部分不仅解释了 CVS 的相关术语，还详细介绍了小组开发环境的建立过程；本系列的第 2 部分则试图以一种简明易懂的方式来讲解 ECLIPSE 小组开发环境的使用方法。
1．前言
版本管理系统可以帮助开发人员有效地管理软件资源（源代码文件、配置文件等）的版本问题。版本管理系统可以帮助开发人员追踪文件的修改履历；防止文件因疏忽而被错误的修改、删除；在小组开发环境中，帮助多个开发人员保持文件的同步；通过文件的修改履历，还可以帮助开发人员发现修改过程中产生的BUG，因此应用CVS可以在一定程度上提高软件的开发效率。现在很多开发工具中都集成了CVS功能，例如ECLIPSE、InteliJ、NetBeans等；虽然ECLIPSE等集成开发环境（IDE）对CVS提供了很好的支持，可以大幅降低CVS的使用难度，但是很多开发人员在使用CVS时还是不知所措。笔者认为这是由于他们不了解CVS的相关术语及CVS的工作模式所致。因此，本文首先介绍CVS的相关术语及CVS的工作模式。然后通过一些实例与应用场景, 展示如何在ECLIPSE中使用小组开发环境。
本文所使用的ECLIPSE没有安装本地语言包插件，操作界面为英文。但理解了相关术语后，读者即使在中文环境中也能正常操作。
2．CVS的相关术语与CVS工作模式
2．1 术语解释
修订版（revision）：CVS版本管理系统用修订版来管理文件的修改履历，修订版用版本号来表示，即修订版号。对文件的每次修改（提交）都产生一个新的修订版。
资源库（repository）：资源文件的集合，版本管理的容器。在ECLIPSE中被称为CVS存储库。
模块（module）：资源文件的组织形式，在版本管理系统中的表现形式为目录（树形结构，可以嵌套）。
输入（import）：将处于资源库之外的软件模块登录到资源库。
输出（export）：从资源库中取出模块。使用export方式取出的模块拷贝不包含版本管理的相关信息，对该模块拷贝的修改也不能反映到资源库。
工作拷贝（working copy）：版本管理系统是一个典型的CLIENT/SERVER系统。用户对资源的修改不是直接在SERVER端进行的，而是根据资源库的内容创建一个本地的工作拷贝，用户在工作拷贝中工作，工作完成后再将修改的内容提交到资源库。
签出（checkout）：获得工作拷贝的操作。此前使用过Visual Source Safe的读者需注意，在Visual Source Safe中的checkout用于锁定文件。
签入/提交（checkin/commit）：将对工作拷贝的修改反映到资源库中的操作。在CVS中使用的术语是提交；在Visual Source Safe中使用的术语是签入。
更新（update）：将资源库中的最新状态反映到工作拷贝的操作。
冲突（conflict）：在资源库同工作拷贝之间状态不一致的状态下进行签入或更新操作时，版本管理系统可能会尽量进行合并，如果版本管理系统不能完全处理上述不一致，就称之为产生了冲突。
快照（snapshot）：在某一时刻，模块中文件状态（包括文件内容及其版本管理元信息）的静态影像。
标签（tag）：由于CVS以文件为版本管理的基本单位，随着开发的进行，对不同的文件的修改次数是不一样的，各个文件的修订版号会因此而变得参差不齐。这不便于模块的管理。为此可以对某个时刻的快照赋予一个标识名称，标识名称就被称为标签。将来通过标签就可以获得模块在该时刻的快照。通过标签所获得的快照是静态的，不能被修改。在ECLIPSE中，标签与版本（Version）是同义词，一般都用于文件集合。需要指出的是：在很多中文资料里，修订版与版本往往不加区分，有时会将单个文件的修订版也称为版本。例如，"A文件最新版本是1.3"，这句话中的版本实际上指的是修订版。因此，需要根据上下文来确定版本的意义。
分支（branch）：分支是一种特殊的标签。从分支中签出的资源是可以被修改的。引入分支是为了更好地支持项目的并行开发过程。
2．2 工作模式
为了解决因多人同时开发而可能产生的冲突问题，版本管理系统有两种常用的工作模式。
模式一：锁定-修改-解锁模式
在这种工作模式中，一个开发人员为了能够修改文件，首先必须锁定文件，锁定文件操作赋予了开发人员修改文件的权力。从一个文件被锁定后到其被解锁前，其他的开发人员不能再锁定该文件。这种工作模式适用于小规模的开发小组。如果采用这种工作模式，开发人员应尽量少、尽可能晚地锁定文件并尽可能早解锁文件。模式一是Visual Source Safe的缺省工作模式。
模式二：拷贝-修改-合并模式
在这种工作模式中，每个开发人员都从资源库获得自己的工作拷贝，然后就可以自由的在工作拷贝中继续开发，开发完成后再向资源库提交自己的工作成果。如果在提交时产生了冲突，则必须在解决冲突后才能再提交。模式二比模式一具有更好的并发性，因而也适用于中、大规模的开发小组。模式二是CVS所采用的工作模式。
锁定-修改-解锁模式是一种悲观的锁定模式，它假定在开发过程中可能会产生大量的冲突；而拷贝-修改-合并模式则比较乐观，它假定在开发过程中软件的设计及开发任务的分配都比较合理（软件的模块化程度高，开发人员一般各司其职），在开发过程中即使会产生冲突，但产生冲突的机率比较小。为了更好地使用CVS，我们在使用CVS时也应该遵循它的设计前提，努力提高软件的设计水平及项目管理的能力，否则将陷入疲于解决提交冲突的尴尬境地。
