CVS 相关内容
CVS 基础
cvs 并不是 eclipse 独有, 而是 eclipse 支持 cvs. cvs 是用于几个程序员之间共享程序避免冲突的一个工具, 是 C/S 架构.
cvs 是 java 的一个开源项目.
cvs 存储库是开发人员存储要共享代码文件的地方. ( repository )
存储库有两种模式:
- pessimistic locking(悲观锁定) 目前服务器采用这种模式, 即同时只能有1个开发人员修改某个source.
- optimistic locking (乐观锁定) 同时可以有多个开发人员一同修改某个source, 提交修改时, 存储库会自动合并所有修改.
默认情况下是使用 “乐观锁定”, 但是个人觉得还是”悲观锁定”好一点. 不会出现矛盾冲突.
eclipse 采用 “乐观锁定” ?
每次提交时, cvs都会为每一个文件分配一个版本号, history 管理.
cvs 还支持同一个模块同时进行多个开发流, 称为”分支”(branch) 一个模块中的主开发流称为”头”(head), 分支是从主开发流中分出的叉, 例如, 一个分支代表项目的一个测试版, 或者添加到代码中首次进行测试的某项新功能.
我们服务器没有使用分支,
1. 首先要创建一个存储库, repository. 共享代码位置
2. 将 eclipse 连接到存储库.( 在eclipse中打开 Repository Exploring 视图-> new-> Repository Location-> add cvs.
这里要输入 cvs 服务器名称, 主机名, cvs存储库, 提供用户名和密码, 等等.
如果你有一个项目想共享, 只需要点这个项目, 右键->Team->share project.
commit 的意思, 是提交文件, 即将文件上传到 CVS 存储库中.
update 获得更新, 即将服务器中的别人更新的内容(别人已经commit), 更新到自己本地文件.
orveride and update, 如果你对某个source进行了修改, 想回退到跟server同步状态, 则使用这个命令.
blog
团队开发中的要求
- 提供方法, 能够协调对源代码的更改, 并能继承这些更改
- 团队提交工作的历史记录
cvs 使用分支(branch) 模型来支持彼此独立而又高度相互依赖的多个工作流程.这些分支是开发团队用来共享和集成正在进行中的工作的地方. 可以认为分支是一个共享的工作台, 当团队成员对源代码进行更改时就更新这个工作台, 这个模型准许从事CVS团队项目开发的每个人在进行更改时与其他成员共享其工作, 以及在项目进展期间访问其他成员的工作.
个人理解,
CVS 全称 current versions system ( 并发版本系统 )
cvs 允许多个开发人员通过一个中心版本控制系统来记录文件版本, 从而达到保证文件同步的目录.
cvs 工作原理 copy-modify-merge （拷贝, 修改, 合并) 具体来说: cvs服务器创建一个源代码库(cvs repository), 苦力可以存放许多不同的项目源程序, 由管理员统一管理. cvs 客户端支持不同平台. 在使用cvs任何源代码库之前, 开发人员需要将项目文件检出到本地(check out), 然后 edit, 最后提交文件(check in)到cvs服务器.
cvs Repository
cvs 源代码库 指的是cvs 存储所有修订版本历史记录的地方, 每个项目都有自己的确定的源代码库, 注意:创建一个新的Repository需要管理员权限.
eclipse 创建心的 cvs repostority 方法如下:
cvs repository视图->右键new->Repository Location->弹出 Add CVS Repository对话框.
1. Location
Location区描述的是CVS Repository的定位信息，包括主机(Host)与存储路径(Repository)。CVS Repository支持local与remote两种方式。对于本地，主机名为localhost或者127.0.0.1，存储路径前缀为 “:local:”。例如，:local:/usr/local/cvsroot表示CVS Repository位于本地/usr/local/cvsroot目录。其URL的写法也因操作系统而有所差别。对于Linux，:local:/usr/local/cvsroot等价于/usr/local/cvsroot。对于Windows，:local:c:/src/cvsroot等价于c:\src\cvsroot。
如果服务器在远端, 以上host可以输入IP地址, 然后存储路径是在这台机器本地的路径, 例如/home/cvs.
Repository的目录分为两部分：$CVSROOT/CVSROOT包含的是CVS的管理文件，而其余部分为用户自定义模块。我们除了使用Eclipse CVS客户端的方式指定Repository之外，还可以通过CVS命令行的方式，如下：
cvs -d /usr/local/cvsroot checkout yoyodyne/tc #–d选项表示direcotry，即CVS Repository对应的目录。
它等价于：
setenv CVSROOT /usr/local/cvsroot
export CVSROOT
checkout yoyodyne/tc
我们来分析一下CVS Repository对应的数据结构。我们假设当前的CVS Repository为/usr/local/cvsroot，如图。CVS Repository目录包含两部分，一部分为administrative files, 给CVS系统管理员使用，记录一些Repository相关的元数据等。另一部分就是源代码目录结构，这里源代码项目的根目录为yoyodyne。
我们服务器, 全部在 cvsroot 目录下
2. Authentication
authentication 描述认证信息
3. Connection
我们是采用默认方式
Connection区描述的是CVS客户端与CVS 服务器端的Repository之间的通信协议。当然，CVS客户端与服务器端可以是同一台机器，此时的主机名为localhost或者 127.0.0.1。按照类型与需求的不同，又分为以下三类协议，分别为：pserver，ext/extssh，pserverssh2。具体含义如 下：
pserver协议：指CVS客户端向服务器发送的密码以明文的方式传送。对于匿名用户，URL为cvs -d :pserver:fun.example.com:/usr/local/cvsroot; 而对于密码用户，按照显式与隐式划分，URL分别表示为：
cvs -d :pserver:doublelife@fun.example.com:/usr/local/cvsroot login
CVS password:
或者
cvs -d :pserver:doublelife:p4ss30rd@fun.example.com:/usr/local/cvsroot login
注意：cvs –d 命令表示指定CVS Repository。
ext/extssh：指使用SSH建立CVS客户端/服务器间的安全连接。因此，从应用场景上说，Pserver通常适用于普通用户或匿名用户，而对 于要求安全性较高的开发人员，则推荐使用ext/extsssh。ext与extssh的区别在于extssh只支持SSH1，而ext支持SSH1与 SSH2。换句话说，extssh是ext的子集，推荐使用ext。需要说明的是，Eclipse CVS Repository透视图本身已经内置有SSH客户端，无需额外的插件。下面是演示的是ext协议对应的CVS命令：
export CVS_RSH=ssh
cvs -d :ext:doublelife:p4ss30rd@fun.example.com:/usr/local/cvsroot
pserverssh2：指的是pserver over SSH2。我们简单的理解为pserverssh2是SSH2与pserver两种协议的叠加。相比pserver与ext/extssh来说，并不常用，这里就不给出示例了。
对于CVS客户端/服务器间的通信协议，除连接类型外，还需要指定服务器端监听端口。服务器既可以使用默认端口，也可以根据需要，指定端口。比 如，pserver协议对应的默认端口为2401，如果该端口被其他的服务器占用，处于侦听状态，此时CVS 服务器可以为Repository指定可用端口。
在完成所有字段的填充后，我们推荐选中“是否在向导完成后验证连接有效”单选框，确保所填信息完整、有效。
作为示例，我们演示一下使用Eclipse来连接著名开源网站sourceforge的FTP软件filezilla的CVS Repository，如下图所示。这里我们采用的是匿名用户，对应的连接协议为pserver，端口默认值。
如之前所述，CVS Repository为树状层级结构。在正式开始copy->modify->merge三部曲之前，有必要花些时间熟悉上图CVS的几个关键概念：Module，HEAD，Branches，Versions，Dates。
Module
如前所述，CVS Repository分为两部分，一部分是CVSROOT，描述CVS工程相关的元数据。另一部分即为Module，表示工程的模块。比如 filezilla分为三大模块，分别为FileZilla，Filezilla Server，Filezilla3。
Head
简单的说，HEAD表示CVS代码的主干与主体部分，正常情况下，我们对CVS的操作三部曲均发生在HEAD目录中。
Branch
我们没有使用 Branch
而对于一些特殊的情况，我们采用的Branch方式。Branch相对于HEAD而言，指的是代码的分支部分，我们简单的理解为补丁。举个例子，假设我 们的项目发布了第一个版本V1.0，第二版本V2.0正在开发当中，处于不稳定状态，随时有代码的改动。而与此同时，客户报告重大的bug，需要我们立即 修复。于是，我们check out V 1.0的代码，调试，并找到解决办法，并发布补丁。为了让补丁与开发代码隔离，我们可以创建一个新的branch，用于V 1.0的补丁，用户从branch中check out的是V1.0的补丁，而不会得到位于HEAD目录的尚在开发阶段V2.0代码。当然根据需要，开发人员可以将branch代码合并至HEAD中。
为更好地说明问题，我们从版本Revision控制的角度来对比HEAD与Branch的关系。一般说来，HEAD的Revision历史呈线性增长趋势，如下图:
由于Branch概念的介入，使得CVS并不局限于线性的开发，HEAD版本可以分为若干不同的Branch，每一个Branch是一个独立开发的自我 维护的开发线。如下图所示，出现了三个不同的分支，分支号的编排依赖于它分离出的主线版本。使用分支号允许一个特定版本分离出多个分支，图中 Revision 1.2同时派生出两个不同的Branch。一个分支也允许派生出多个子分子，Branch 1.2.2派生了一个sub branch。
一个Branch的变更可以很容易转移到HEAD中。可以通过CVS命令update配合-j选项实现合并。这里的-j表示join。
举个例子，我们当前的HEAD版本为1.4。现在需要将分支1.2.2合并到HEAD。
我们假设模块”mod”只包含一个文件”mod.c”。分支1.2.2分配了一个名字叫R1fix。
CVS checkout mod #检出最新版本1.4
CVS update –j R1fix m.c #合并所有分支中的变更，即1.2与1.2.2.2.2的合并
CVS commit –m “Included F1fix” #建立新版本1.5
下图就是合并后的Revision历史结构。
在合并过程中可能会发生冲突，可以通过手工地方式解决。
Versions/Tag
我们没有使用 Versions
Version是标签Tag的集合。所谓Tag指的是当项目达到某一个milestone时，对所有文件做一个标签，记录历史记录。通常对一个release做一个tag，如下图所示。
类似 老李所说的 excel 管理, 有里程碑一样的修改完成后, 做一个 save as
为更好地理解tag的工作原理，我们可以将 tag 想象成为一条在由文件名和修订号组成的矩阵上穿过的“曲线”，如下图所示：
当我们将该 tag 曲线上的 * 标记拉直后，你就得到了由所有 tag 修订号组成的如下图的水平线：
由于tag的目的是记录开发历史，因此人们通常不会删除或者改变标签。对tag的删除，移动，重命名多半是因为临时使用标签或者不小心放错位置。警告，下列命令会永久删除历史信息，使用时应尽量小心。
cvs rtag -d rel-0-4 tc
Dates/Tags
与Versions一样，Dates也是标签Tag的集合。区别在于前者以版本作为tag的标记，而后者则以时间为标记。相比与Date类型，Version Tag更加常用。
为了更好的全面理解这些核心CVS概念，我们通过Show History视图将这些概念串联起来，如下图所示。
有对了相关概念的理解，接下来，我们将介绍CVS的常用操作。相信大家对日常的操作如update，commit非常熟悉，只做简单介绍。更多地是关注那些容易忽视但是特别使用的命令。
作为三部曲之一的Copy操作，CVS对应的命令为check out。具体操作是，选择HEAD目录下的目标源文件夹，右键单击Check Out，如图：
Check Out
Check out之后的本地工作目录与CVS目录一致。如果想自定义文件夹的根目录，则可选择Check Out As命令。
Switch to another Branch or Version
作为三部曲之二的Modify操作，除正常的源代码变更操作外，对应一个非常重要的Eclipse CVS命令，即Switch to another Branch or Version，即切换到其它分支或者标签做源代码的修改，如图：
Merge
作为三部曲之三的Merge操作，除正常的update/commit外，也对应的一个非常重要的CVS命令merge，即将branch或tag与HEAD中的Base version进行合并，如图
Branch
此外，如果想创建一个新的分支，可通过右键Team -> Branch打开Create a new CVS Branch。
Tag
如果需要发布一个新的版本2.0.6，可以新创建一个Tag。步骤为右键源代码工程 –> Team -> Tag as
Version，如图。通过CVS Repository透视图可以查看相应的Tag。
Patch
补丁(patch)允许开发人员共享尚未提交到CVS的代码变更。补丁程序包含的是本地资源与CVS资源库的差别CVS Diff命令。补丁在许多场合都非常有用：
· 由于权限的限制，需要将补丁程序发送给权限用户提交。
· 需要一个临时工作区间隔离待提交的代码。
· 在提交CVS之前，需要对更改的文件测试，可以将补丁程序发送给测试人员。
要创建一个补丁，使用右键Team –> Create Patch，开启Create Patch向导完成补丁文件的创建。
这里我们将补丁程序导出成文件patch.txt。按照默认方式完成向导。patch.txt内容如下：
### Eclipse Workspace Patch 1.0
#P source
Index: AsyncGssSocketLayer.cpp
===================================================================
RCS file: /cvsroot/filezilla/FileZilla/source/AsyncGssSocketLayer.cpp,v
retrieving revision 1.14
diff -u -r1.14 AsyncGssSocketLayer.cpp
--- AsyncGssSocketLayer.cpp 4 Mar 2005 10:35:04 -0000 1.14
+++ AsyncGssSocketLayer.cpp 28 Nov 2011 07:26:39 -0000
@@ -1,6 +1,6 @@
// GSSAsyncSocksifiedSocket.cpp: implementation of the CAsyncGssSocketLayer class.
//
-//////////////////////////////////////////////////////////////////////
+//////////////////////////////////////////////////////////////////////
// Part of this code is copyright 2001 Massachusetts Institute of Technology
#include "stdafx.h"
patch.txt实际上是CVS Diff命令的输出，从而实现了CVS Repository之外的资源共享。相应地，开发人员可以共享补丁程序。
Apply Patch命令提供了打补丁的方法，如图所示。
比较&替换
人生没有后悔药，但是Eclipse提供了，而且特别简单。快捷菜单操作Replace With和Compare With提供了本地历史记录与CVS Repository比较与替换的机会。需要说明的是，CVS Repository的资源既可以是HEAD也可以来自某一个分支，或者某一个tag。
重命名
一般情况下，要避免对CVS Repository作重命名操作。对于工程而言，CVS对待重命名后的工程为新工程。相应地，需要使用Team -> Disconnect操作解除项目与CVS的关联，然后再对项目重命名，最后，在重新连接到CVS之后，需要像其它新的工程一样定义。而对于文件而言，重命名会导致出现一个新的文件，不过幸运的是，原文件的内容会被拷贝到新的文件中。
CVS vs SVN
至此，相信读者对Eclipse CVS客户端有一个基本的了解。不过，CVS并非是完美的。下面我们来比较下两者的一些主要的不同点，如下表。
存储类型存取速度事务总体评价
CVS文件相比SVN慢没有实现4
SVN数据库相比CVS快完全实现5
实际上，CVS是一个古老的系统，其内部结构有许多改进之处。知道今天，仍有人想重头开始，重写CVS，但都未能成功，SVN的开发人员花了很多时间与心思在改进内部结构，使其变得简单、优雅，甚至有人认为SVN是CVS的接班人。
