文档介绍：在Eclipse中使用版本控制系统CVS2003-12-19作者:丰伟目录前言 3背景 3Eclipse的内置版本支持 4CVS 5基本概念 5CVSNT的安装 7在Eclipse中使用CVS系统 9基本工作流 9设置资源库的位置 10共享项目 12启用CVS资源修饰 17导出项目 18与CVS资源库同步 20更新 20提交 24从分支合并 24相关资源 25前言项目的版本控制对于团队开发是极端重要的,对于个人开发者也是项目复杂化时不可缺少的工具。本文介绍如何在Eclipse中使用版本控制系统CVS。首先,我们将简要讨论一下团队代码开发的思想,然后简要讲述CVS系统的背景及Windows平台下CVS服务器的安装和设置。接下来,针对Eclipse,详细讲解了使用CVS进行团队开发时的开发流程以及在Eclipse中具体使用的重要操作方法。背景现今的大多数应用程序是由多人组成的团队开发的。即使只涉及几个开发人员的小项目,也需要对源代码的更改进行严格控制。这就是源代码管理软件的任务。源代码版本控制软件必须支持两个核心功能:提供一种方法,能够协调对源代码的更改,并能集成这些更改团队所提交工作的历史记录当团队成员完成新的工作时,通过将这些更改提交到资源库(repository)中来共享他们的工作。类似地,当他们希望获得最新可用的工作成果时,就可以根据资源库中的更改,更新自己的本地工作空间(Workbench)。这意味着资源库的内容会因团队成员提交新工作成果而经常发生更改团队成员都要能够根据资源库更新自己的工作空间,确信它们是最新的。维护历史记录也很重要,那样就可以将当前工作与先前版本进行比较,如有必要,还可以回复到先前版本。协调团队的工作,以便只存在唯一的当前项目状态定义,以及包含团队已集成的工作,这些对于管理版本控制也是十分必要的。这种协调有可能是最难实现的目标。最理想的模型是:团队的任何成员都可以对自己有权访问的任何资源进行更改。因为两个团队成员可以提交对同一资源的更改,所以有可能发生冲突,必须解决这种冲突。这种模型假定冲突具有唯一性。但遗憾的是,没有任何源代码是孤立地存在的;通常它包含与其它资源隐式或显式的相关性。但源代码管理软件的工作就到此为止了,因为它并不能取代项目管理。项目管理者必须履行其职责:协调其它成员的工作以及负责进度、项目阶段和发布日期。此外,源代码管理也不能替代开发人员之间的交流。Eclipse的内置版本支持Eclipse本身内置了一定程度的版本支持,也就是所谓的LocalHistory。在Eclipse中编辑的文件每次存盘都会留下记录,可以随时与历史记录比较,恢复到某一个时刻的状态。在资源视图(ResourcePerspective)或者Java视图(JavaPerspective)中的文件上点右键,pareWith,LocalHistory,就会得到如下的画面,可以很清晰看到各个版本的区别。图1:Eclipse中的内置版本支持:LocalHistory。如果需要,则可以通过ReplaceWith,LocalHistory来恢复到任一个以前的版本。当然,这样版本的历史是有限制的,可以在Eclipse的Preference中设置。在Preference―>Workbench->LocalHistory中,可以设置保持最多保持几天的文件,每一文件的版本数目,历史文件的大小限制。但是,这样的版本系统只实现了最基本的版本功能,如果想把文件某一个状态标记为一个版本,加上注释(仅仅从LocalHistory中的保存时间很难看出每一个版本的特点,也难以找到重要的关键版本),或者想把某个目录乃至整个项目版本化,Eclipse内置的LocalHistory都是无能为力的。CVS好在Eclipse平台提供了作为团队在软件项目中共享代码和工作的能力。Eclipse平台体系结构的重点在于工作空间。工作空间维护构建和测试软件项目所需的一切,它包含源代码和所需其它资源文件。工作空间是在开发人员的本地机器上进行维护的,但整个团队通过源代码管理系统进行协作,不同开发人员的代码在源代码管理系统中进行汇集。Eclipse平台只对一个源代码管理系统提供内置支持:并发版本控制系统(ConcurrentVersionsSystem,CVS)。CVS是ConcurrentVersionsSystem(并发版本系统)的缩写,诞生于1986年,现在已经发展成了最流行的针对软件开发人员的源代码版本管理解决方案。CVS是用于代码版本管理的开放源码的客户机/服务器解决方案,它可用于各种平台,包括Linux和WindowsNT/2000/XP。通常,CVS的主要功能是记录源文件的历史。当一组开发人员从事同一个项目时,CVS将他们彼此隔离开来。每个开发人员都在他/她自己的