一、版本控制的概念以及几种版本控制工具的简介
1.源文件的标示与版本的概念
源文件是一个软件最为重要的一个组成单元,因此源文件的管理也是整个软件组成管理中最重要的一环,是进行高效软件开发的关键岁所在.对源文件进行管理,必须对源文件进行标示.通常认为只需文件名.而实际上,在一个版本维护工具下对于源文件的标示包括两部分:文件名与版本.即:源文件可以用如下的二元组表示 {filename,version};
所谓版本,一般的软件开发人员都有一个直观的理解,但却很难做出准确的定义.版本,是指某一特定对象的具体实例的潜在存在.这里的某一特定对象是指由版本维护工具管理的如软件组成单元,一般指源文件.具体实例则是指软件开发人员从软件储藏室中恢复出来的软件组成单元的具有一定内容和属性的一个真实拷贝.
把版本定义成一个潜在的存在是基于以下考虑:版本作为源文件的一个表示部分,软件人员对它的引用实际上想得到不同的版本对应的不同源文件,所以说版本是一种抽象.它用来定义一个具体实例应该具有的内容与属性.也就是说版本是一个具体实例的潜在存在,是源文件不同化身的抽象.
有了以上对版本概念的认识.大家对版本维护工具就有了一定的理解:版本维护工具,应该对开发人员屏蔽源文件的存储方式对开发人员是透明的,开发人员不需要明白软件存储库里有什么源文件,只需要说明需要什么样的源文件以及要存储什么样的源文件,版本维护工具自动完成这一切工作.关于版本维护的理论还包括:版本的空间,维数,版本的表示,存储,合并等理论,因为我们这里主要说明cvs 的linux 服务器,所以一切从简,对这方面有兴趣朋友可以阅读相关书籍
本章所讲的cvs 就是这样的一个强大的工具.在讲述cvs 前我们先介绍其他几个版本维护工具.
2.几种版本维护工具的简介
2.1 SCCS
SCCS的全称是Source Code Control System .在介绍之前先定义工作文件的概念.所谓工作文件,是指从软件储藏室得到的有”写”权限的源文件.
SCCS 是一种基本的源文件版本控制工具,它适用于任何正文文件的版本维护.它基于单一文件的版本控制,通常,它的软件储藏室和要维护的文件在同一目录下.
SCCS 工作时,有一个专门的SCCS 格式的文件保留其源文件的编码版本,其记录了足够的信息来生成新的版本,并记录了谁对文件有修改权,拥有该版本的”锁”.
SCCS的版本好事一个四元组,即:发行号,级号,分支号,序号(release,level,banch,sequence)
2.2 RCS
RCS是另一种基本的源代码管理工具,是WALTER.f.Tichy 于1980 年在Indina的 Purdue 大学开发的.RCS和SCCS 类似,也是基于单一文件的版本维护系统.RSC 通过RSC 文件进行文件管理;使用RCS 进行维护的过程与SCCS 相似,也是按恢复提交模式进行的,不多赘述
RCS文件,是RCS 系统中源文件的储藏室,它是一种特殊的编码文件,包含了开发人员恢复老版本的源文件以供开发使用的足够信息.它通常是以.V 为后缀
它的结构如下:
* RCS 头,这一部分记录了对应文件的版本树的头版本号,
* 版本描述: 这一部分描述RCS树上的各个节点的属性性质
* 初始信息:之一部分是在创建第一个RCS 版本时的表述内容
* 文件内容
RCS与SCCS 相似,RCS将所维护的版本也组织成树形结构.但RCS允许多重分支,即,RCS的版本号不像SCCS那样是一个四元组.形式为;发行号,级号,[分支号,序号].版本树如下
2.3 综述
这两种版本维护工具的共同点是:采用了”锁”的方式,对当前问坚持有”锁”的用户才有对文件的修改权.他们采用的机制是所谓的” lock-modify-unlock”.采用这种即只有一个知名的弱点,那就是不至此多用户并发的使用.
二、在linux 下构建cvs 服务器
1.CVS简介及基本原理
CVS 的全称是Current Version Control. CVS是一种GNU 软件包.由Intersolv公司开发,最新的版本是 1.10.8.它是一种基于RCS系统的维护工具.它明确的将源文件的存储和用户的工作空间独立开来,有在一定的模式上扩展了RCS的恢复提交功能. 并使其有利与并行开发.
CVS 将源文件的RCS 文件根据其源码树的层次集中在一个目录下,该目录的绝对路径由环境变量CVSROOT 定义.
可见该目录可以分成两部分:一部分为${CVSROOT}/CVSROOT,它包含CVS所需的一些管理 文件.另一部分为源文件所形成的RCS 文件,并按软件开发的源码树的结构来构成.
2.CVS 在进行源代码管理时的特点
2.1 源代码空间与用户空间分离.
CVS 系统将源代码文件放在repository下,用户要修改文件必须将repository 下的文件作一个拷贝之后才能进行,
2.2 并发访问
CVS 系统允许多个开发人员同时获取同一文件的的同版本源文件.当然这也是CVS获得广泛应用的主要原因．开发人员提取一个文件时，将在自己的工作空间建立一个与其他开发人员相互独立的拷贝，此文件的版本号与文件“头”版本相同，除非他用commit 命令完成版本的永久性升级.而此时,其他用户可用 undate 命令是自己的版本号与”最新的头版本号”相一致.:若用户在checkout 后发现头版本改变了,可用RCS系统的rcsmerge 命令形成一个新文件,这个新文件及包括原来的内容,又包括用户修改的内容.此示弱与其他同时在对同一文件修改的开发人员发生冲突,可通知他们进行手工修改
所以说,CVS系统是一个Copy-Modify-Merge 的算法而不是以上我们提到的那两个系统所采用的lock-modify-unlockj机制 这种算法的好处在于,软件开发人员可以得到一份源文件的拷贝(Copy),并不会对该文件上”锁”,因此为并行开发提供了可能,在得到 拷贝后, 开发人员可以在自己的开发环境下进行修改(Modify),然后提交自己修改后的文件,与源文件进行合并(Merge).形成新的版本,
2.3 源文件共享
CVS对${CVSROOT}的使用是不同的用户可按自己的需要拷贝不同的模板,修改后载体交给${CVSROOT}.这样用户可共享源文件.这当然是我们建立CVS服务器所必需的
2.4 独立的工作环境
用户在自己的工作环境下进行修改开发,自然有独立的工作环境,值得说的实.CVS 也支持”锁”的机制.允许用户对自己获得的模板拷贝进行锁定
2.5 标记
CVS为了方便用户,引入了一个tag文件,该文件位于用户工作目录下,与被他标记的文件一级的CVS 目录下对特定的tag 文件操作,即对相应版本的操作,即使这个版本被修改过.
3.CVS 的获得安装
CVS 在一般的linux发行版本中都有默认的安装.如果你的系统没有安装也没有关系,CVS可以在intenet 上很方便的得到. 它的源码在 ftp://202.113.29.4/pub1/unix/cvs 它的说明文档在ftp://202.113.29.4/doc/cvs.任何人可以很方便的下载.目前他的最新版本是2..10.8..
安装过程大致如下:
在任一目录下解开下载的压缩文件.
利用文件包内的安装工具,完成安装,(内有说明文档).
通常是:make config 和 make install
(不通版本的,安装方法可能不同,具体的请参见,它自身所带的安装文档)
4.服务器的安装使用
在安装完CVS 系统后我们便可以开始CVS仓库的安装. 在linux环境里,CVS的使用一般是以命令行方式,也有一些GUI的前端工具,如 TKCVS等.这里我们将应用CVS 的一般命令即 cvs [cvs的选项] cvs-command [command 选项] 的方式完成服务器的配置.
4.1 软件仓库(repository)的管理
创建CVSROOT根目录
首先编辑有关的环境变量.(CVS的几个重要的环境变量如下:
CVSROOT 仓库根目录的完整路径名
CVSREAD 如果设置,表明在checkout操作时所有的文件都置成只读
CVSBIN CVS利用了很多RCS的命令,指定乐RCS工具的路径
CVSEDITOR 指定用户书写日志信息所使用的编辑器
CVS_RSH 启动一个远程CVS服务器时,所使用的shell的名称
CVS_SERVER 决定"cvs server"的名字,缺省是CVS
CVSWRAPPERS cvswrapper脚本, 用来指定包装文件名.)
其中中重要的是CVSROOT,它指明了仓库所在的位置,在创立新的仓库时,它是必不可少的.因此一般需要加入环境变量CVSROOT的定义.如在 /etc/bashrc 文件中加入下面两行
CVSROOT=/cvsroot
export CVSROOT
或者直接在命令行上执行
$ export CVSROOT=/cvsroot
然后在相应位置开始创建CVSROOT
$mkdir cvsroot
$cvs init
如果没有定义变量CVSROOT 会出现这样的提示:
cvs init : No CVSROOT specified! Please use the ‘-d’ option
cvs [initn aborted]:or set the CVSROOT environemnt variable
如果你是在不想定义环境变量,你可以用这样的命令:
cvs –d /cvroot init 不过即使你定义了CVSROOT,参数 –d 后的内容也会覆盖它.如果没有错误提示, 恭喜你, 你的CVS 软件库已经建立好了.
剩下的问题就是怎样时多用户来使用这个仓库来进行并行的软件开发与版本控制.还有作为CVS 管理员你应该设置你的用户的权限. 此时,你的cvsroot 下有一CVSROOT 子目录.他下面的文件时CVS 的配置文件,用
ls /cvsroot/CVSROOT 有一系列文件,他们的用途分别是:
checkoutlist 支持CVSROOT目录的其它管理文件,允许为各种CVS命令定置信息
commitinfo 在cvs commit命令执行时,这个文件指定乐文件提交时执行的命令
cvswrappers 定义乐一个包装程序当文件登记或检取时就会执行.
editinfo 允许你在commit命令启动前在日志信息被记录后执行的脚本
history 跟踪所有影响仓库的命令
loginfo 类似coimmitinfo, 只是在文件提交后执行
modules 允许为一组文件定义一个符号,否则必须为每一个要引用的文件指定cvs仓库的路径名($CVSROOT)
nitify 控制从"watch"来的通知."watch"由"cvs watch add"和"cvs edit" 设置
rcsinfo 为commit log回话指定一个模板.
taginfo 定义乐在任意"tag"操作后执行的程序.
Passwd 缺省没有.存储用户passworld的文件
设置管理权限:
源码管理员应对仓库下的文件和目录设置恰当的许可权限来控制访问. 所有的RCS文件(以,v结尾)是只读方式,仓库中的目录应当对使用者有写权,以便允许其更改.
多个软件库的建立
如果你有几个开发组, 他们的工作毫不此相干,你完全可以建立几个不同的软件库.你要做的只是要重新定义一下环境变量CVSROOT,或者,使用-d 来设置,使用多个软件库的好处是,他们可以在不同的sever上,CVS 1.0 版还不能用一条命令来从不同的软件库中取出文件,在她以后的版本中,你可以将不同SEVER 上的源码取到你的工作目录下. 以下是一个怎样在多软件库下建立工作目录的例子:
cvs -d server1:/cvs co dir1
cd dir1
cvs -d server2:/root co sdir
cvs update
第一条命令建立了一个工作目录,在sever1上取出了文件第三条命令则在sever2 上的软件库中取出了一些文件.然后用所有的文件使sever2 上的文件升级.
