CVS版本控制

CVS版本控制软件的安装配置与使用

http://blog.csdn.net/sunxy5291/article/details/1566223

 

在eclipse中使用分支合并功能 CVS 
http://blog.csdn.net/xiyuan1999/article/details/5733409

 

可下载文档：

Eclipse中的CVS使用

 

-------------------------------------------------------------------------------------------------------

总结：

在开发告一段时间，就要打包一个版本
如果已经打包版本，后来想向这个版本里加新内容，是可以的，操作时勾选“如果标记已存在，则移动”
可以在主干上接着开发新版本，在开发告一段时间，就要打包一个版本
修改BUG时，可以决定在哪个版本基础上修改，拉一个这个版本的分支出来再修改，分支最终要合并到主干
提交” 操作只能将文件提交到HEAD 或分支上。

-------------------------------------------------------------------------------------------------------

原文件请看附件中的word文档 :Eclipse中的CVS使用

1.5 在 CVS 上为软件打包一个版本

在开发告一段时间，就要打包一个版本，打包版本的操作步骤如下：

（1 ）右键单击“项目名”，在弹出的快捷菜单中选择“小组→标记为版本”选项。此时如果有修改，但没有提交到CVS 上，则会弹出下如图1.20 所示的一个提示框，如果单击“确定”按钮，则未提交的修改就不会包含在本次打包的这一版本中。

（2 ）如图1.21 所示，在窗口中为此版本起一个名称为V001 。由于此名称可能已存在于CVS 中，所以下面还有一个复选框，如果选上该复选框，在打包时就会替换掉同名的老版本；如果没有选上，则在有同名版本时，就会弹出错误提示框。

图 1.20  确认未提交的更改                       图 1.21  给版本起名

如果版本已经打包，但后来发现有一个文件有点问题，于是想把这一个修改的文件更新到上一个版本中，但另外一些修改的文件则不想更新到上一个版本。这时如果再通过右键单击项目名来打包，则项目所有修改的文件都会被更新到上一个版本中。

正确的操作步骤如下：

（1 ）将修改的文件提交到CVS 上。

（2 ）右键单击该修改文件的“文件名”，在弹出的快捷菜单中选择“小组→标记为版本”选项。

（3 ）在图1.21 中，还是起名V001 ，并且要选择复选项，然后单击“确定”按钮。

此操作和打包项目版本惟一不同之处是：前者右键单击“项目名”，后者右键单击修改文件的“文件名”。

说明： CVS 打包版本并非是将项目文件再复制一份，如果去c:\cvsfile 目录中查看提交的项目文件，就会发现项目文件只有一份，这一份文件中会记录着每一次的更改，所以CVS 打包版本只是做了一个更改位置的标志。

1.6  将项目替换成 CVS 上的其他版本

接着1.5 节内容，当打包成版本之后，如果要将此版本还原回项目中，则操作步骤如下：右键单击“项目名”，然后在弹出的快捷菜单中选择“替换为→另一个版本或分支”选项，得到如图1.22 所示窗口，选择版本V001 ，单击“确定”按钮。

注意： 此操作会将本地所有的修改都覆盖掉，所以在操作之前先把本地修改提交到CVS 上保存。

图 1.22  CVS的分支版本列表

1.7  修改旧版本的 BUG

如果已经发布了软件的1.0 版，而现在正在开发2.0 版，但用户在使用1.0 版的时候发现了一些BUG ，这时就需要修改1.0 版的这些BUG ，具体修改操作步骤如下：

（1 ）将CVS 导出成另外一个项目。参见1.3.3 小节，其他步骤都一样，仅在最后一步时，输入另外一个项目名myproject2 。这样分成两个项目后，修改旧版本和开发新版本就可以同时进行而不互相干扰。

（2 ）用1.6 节的替换版本操作将myproject2 项目替换成V001 版本（假设V001 就是出问题的1.0 版）。如图1.23 所示，在图中可以看到myproject2 的后面跟着一个V001 版本     标志。

图 1.23  从 CVS导入的 myproject2

（3 ）这时还不能在myproject2 上修改，即使修改了也不能提交CVS 。因为还差一步，即需要为V001 版创建一个分支，操作步骤如下：右键单击myproject2 的项目名，然后选择“小组→分支”选项，在弹出如图1.24 所示的窗口中输入分支名V001_patch ，并单击“确定”按钮。

说明： 很容易把“ 分支” 和“ 版本” 看成类似的概念，但实际上“ 分支” 是和HEAD 的概念比较接近，“ 提交” 操作只能将文件提交到HEAD 或分支上。

（4 ）如图1.25 所示，myproject2 的项目名后就有了一个分支名V001_patch ，表示该项目已经在这个分支下工作了。

图 1.24  设定分支名                     图 1.25  myproject2在 V001_patch分支下

（5 ）现在可以在myproject2 项目中将BUG 修改好，并提交到CVS 上了。修改不是提交到HEAD 上，而是提交到分支V001_patch 上，所以不会影响到软件2.0 版的开发。提交之后，文件尾部的版本号也起了变化，如图1.26 所示。

图1.26  在分支下的程序版本号  

（6 ）当修改完BUG 后，就可以给软件再打一个版本V100_1 ，并将修正了BUG 后的版本发布给用户。

-------------------------------------------------------------------------------------------------------

 

我 们的项目在某一阶段通常会发布一个版本，供客户进行使用，然后我们会继续开发下一个版本，如果这时候客户正在使用的那个版本发现了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也可能经历多次与主枝的合并。