在eclipse中使用分支合并功能 CVS

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）：分支是一种特殊的标签。从分支中签出的资源是可以被修改的。引入分支是为了更好地支持项目的并行开发过程。
一.工作模式
为了解决因多人同时开发而可能产生的冲突问题，版本管理系统有两种常用的工作模式。
模式一：锁定-修改-解锁模式
在 这种工作模式中，一个开发人员为了能够修改文件，首先必须锁定文件，锁定文件操作赋予了开发人员修改文件的权力。从一个文件被锁定后到其被解锁前，其他的 开发人员不能再锁定该文件。这种工作模式适用于小规模的开发小组。如果采用这种工作模式，开发人员应尽量少、尽可能晚地锁定文件并尽可能早解锁文件。模式 一是Visual Source Safe的缺省工作模式。
模式二：拷贝-修改-合并模式
在这种工作模式中，每个开发人员都从资源库 获得自己的工作拷贝，然后就可以自由的在工作拷贝中继续开发，开发完成后再向资源库提交自己的工作成果。如果在提交时产生了冲突，则必须在解决冲突后才能 再提交。模式二比模式一具有更好的并发性，因而也适用于中、大规模的开发小组。模式二是CVS所采用的工作模式。
锁定-修改-解锁模式是一种悲 观的锁定模式，它假定在开发过程中可能会产生大量的冲突；而拷贝-修改-合并模式则比较乐观，它假定在开发过程中软件的设计及开发任务的分配都比较合理 （软件的模块化程度高，开发人员一般各司其职），在开发过程中即使会产生冲突，但产生冲突的机率比较小。为了更好地使用CVS，我们在使用CVS时也应该 遵循它的设计前提，努力提高软件的设计水平及项目管理的能力，否则将陷入疲于解决提交冲突的尴尬境地。

 

我们的项目在某一阶段通常会发布一个版本，供客户进行使用，然后我们会继续开发下一个版本，如果这时候客户正在使用的那个版本发现了bug，我们当 然需要更改bug，并且给客户发布更新补丁包。这时就需要创建基本此版本的一个分支，分支创建完成后，我们同时还需要将此bug在我们的未来版本中消除 掉。因此需要将此分支的更改合并到我们的下一个版本中，也就是我们目前正在使用的head工作空间。因此理想的流程为：

    发布版本A1.0 ---〉继续开发下一版本A1.1 ----〉版本A1.0发现存在bug ----〉checkout此版本，修改存在的bug ---〉将修改创建分支branch_A1.0_bug1 ---〉发布更新补丁 ----〉将分支合并到主工作空间中。

  二、  在eclipse中的使用步骤：

    1、选择项目，单击右键--〉team--->tag as version... 。此步骤创建一个版本

    2、继续开发项目的下一个版本

    3、客户发现存在bug，检出客户正在运行的版本。选择项目，单击右键---〉Replace With --->  Another Branch or Version，选择客户正在使用的版本。

    4、在当前工作空间（客户运行版）中修改程序，完成bug修改。

    5、创建该版本的分支，选择项目，单击右键---〉Team ----> Branch...。创建修改了该bug的分支。

    6、给客户发布更新补丁。

    7、将该分支合并到主干版本中。

          a 选择项目，单击右键---〉Replace With---->Another Branch or Version，选择head，载入主版本。

          b 选择项目，单击右键---〉Team ---> Merge...，选择起点版本，即客户A1.0版，选择下一步，然后选择分支                  branch_A1.0_bug1 ，最后点击完成。在cvs的视图中将会显示这个分支的更改，将这些更改合并到工作空间                中，这样主工作版本，就已经同样修改了该bug。

    8、一切完成，同步，提交。

    注意：分支合并是比较版本A1.0和这个版本下的分支之间的不同，将这些不同合并到Head中。 

我们打开图图Eclipse的CVS视图,可以看到一个服务器下可以分为三部分

HEAD、Branches、Versions先要理解这三部分的作用

HEAD:当前项目的主干版本，我们平常的开发都是在HEAD下开发。

Versions：在HEAD下面开发完一个完整的版本后就要打版本。也就是存储这个项目的一系列的版本。

                  选择项目，单击右键--〉team--->tag as version... 。此步骤创建一个版本

Branches：每一个版本下面可以有分支。

                 创建该版本的分支，选择项目，单击右键---〉Team ----> Branch...。

Every CVS repository has at least one branch, referred to as HEAD.（每个项目至少有一个Branch，该Branch被称为HEAD）

Under certain conditions, more than one branch may exist in a repository. For example, one branch may be for ongoing work, and another branch may be for maintenance work.

（某些条件下，会有多个Branch，比如一个Branch是用来推进工作的，另一个是用来维护的。这个我们经常遇到，比如我们开发完了一个版本在生产系统上跑着；后来有了新的业务需求，我们需要增加新功能，同时还要能运维以前的版本。）

由Branch够成一个代码树。

开始的时候，任何一个module都有一个主枝被称为'HEAD'。Branch是一棵正常生长的代码树中的枝杈。

一个branch最终要么被合并到主干中去，要么被结束。branch通常用来debug,如果这个bug被fix了，修改bug的代码应该被合并到主枝上去。 一个branch也可能经历多次与主枝的合并。

    提交冲突解决：小组----先同步-----右击需同步的文件-----覆盖更新

版权冲突时：

1.       当所修改的版权比svs上的还旧怎么办?

方法一：先得到最新版权，再同步，然后修改，最后提交。

方法二：将修改的文件和最新比较，将最新版的内容复制到修改后旧文件中，再提交。

2.分支合并主干版本：

 选择项目，单击右键---〉Replace With---->Another Branch or Version，选择head，载入主版本。