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时也应该遵循它的设计前提，努力提高软件的设计水平及项目管理的能力，否则将陷入疲于解决提交冲突的尴尬境地。

cvs 安装见http://hi.baidu.com/wangyu1987530/blog/item/ad060446d487fa0f6a63e508.html

3 文件的提交和更新

1．将修改的文件提交到CVS

在HelloWorld.java中增加一条输出语句“System.out.println("第一次修改");”，然后保存。右键单击窗口右侧“导航器”视图中的HelloWorld.java文件，在弹出菜单中选择“小组→提交”选项，如图5.13所示。

 

图5.13 提交界面

2．从CVS更新文件到本机

删除掉HelloWorld.java中的语句“System.out.println("第一次修改");”然后保存，这时要将CVS服务器上的最新代码更新到本地，有以下两种方法：

（1）右键单击HelloWorld.java文件，在弹出的菜单中选择“替换为→HEAD的最新内容”选项。

（2）右键单击HelloWorld.java文件，在弹出的菜单中选择“小组→与资源库同步”选项，在弹出的同步界面，如图5.14所示，单击“将当前更改从右边复制到左边”按钮，然后保存。

 

图5.14 资源库同步界面

读者可能会问：“右键单击HelloWorld.java文件，然后选择‘小组→更新’这种更新方法，为什么不用呢？”

这种更新方法是将CVS的最新版更新到本机，当本机文件没有修改的时候才用这种方法。如果对HelloWorld作了修改，CVS上的反而是旧内容了，这时再用这种更新方法则对本地的HelloWorld.java文件不会产生任何影响。

4 解决文件提交的冲突

在多人项目开发中，由于同时修改一个文件，一时就会产生提交冲突，本小节就来说明一下如何解决这种冲突。

在上面检出项目时，已经另外安装了一个Eclipse，相当于多了一个开发者，原来的称为Giles，新加入的叫Tom。Giles和Tom电脑上的HelloWorld.java的版本都是1.2。这时Giles在文件中增加一条语句“System.out.println("Giles第1次修改");”，同样Tom也在文件中作了类似修改，如图5.15所示。

 

图5.15 两开发者对代码的修改情况

Giles先提交HelloWorld.java文件，这时版本变成了1.3，由于Giles是第一个提交的，所以他不会遇到代码冲突。Tom编程速度慢一些，所示后提交，这时就会和Giles先提交上去的代码产生冲突。因为如果用Tom的代码更新CVS，则Giles的修改就会被冲洗掉，所以Eclipse此时就会报文件冲突，不允许直接提交。那么Tom该如何提交自己的修改呢？解决办法如下：

右键单击“HelloWorld.java→小组→更新”选项，如图5.16所示。

 

图5.16 更新后的界面

此时HelloWorld.java的版本已经变成了1.3，更新后的冲突也已标记出来。这时就可以根据代码中的标记来合并修改，修改完毕后再提交到CVS，此时版本变成了1.4，如图5.17所示。

 

图5.17 代码合并修改后的界面

Eclipse考虑得很周到，在文件更新时，会将Tom的旧文件保存为一个称为“.#HelloWorld.java.1.2”的备份。这个备份文件不会被提交到CVS，因为Eclipse中已经将这类文件作了忽略设置。忽略设置的界面如图5.18所示，在主菜单选择“窗口→首选项”选项可打开此窗口。

5 如何忽略掉不想提交的文件

假设当提交一个项目时出现如图5.19所示的情况，图中的bin目录包含的是编译后的class文件，没有必要将它提交到CVS上。我们可以右键单击它，然后在弹出的快捷菜单中选择“添加至.cvsignore”，这样bin目录就被忽略掉，不会提交到CVS上。

 

图5.18　提交到CVS时被忽略的资源的设置界面

 

图5.19 忽略提交