取代 CVS 的版本控制工具 —— Subversion

在开源软件领域,并行版本系统(CVS)一直使版本控制的选择。

恰如其分的是,CVS本身是一个自由软件,它的非限制性的技法和对网络操作的支持(允许大量的不同地域分散的程序员可以共享他们工作的特性)非常符合开源软件领域合作的精神,CVS和它半混乱状态的开发模型成为了开源文化的基石。

但是像许多其他工具一样,CVS开始显露出衰老的迹象。

Subversion是一个被设计成为CVS继任者的新版本控制系统。设计者通过两个办法来争取现有的CVS用户:使用它构建一个开源软件系统的版本控制过程,从感觉和体验上与CVS类似,同时Subversion努力弥补CVS许多明显的缺陷。

Subversion 可以在多种不同的操作系统上运行,它的主要用户操作界面是基于命令行的,但现在已经开发出很多可以运行在不同操作系统上的客户端以及多种开发工具的集成套件。

下面从几个方面具体介绍 Subversion

Subversion是什么?Subversion是一个自由/开源版本控制系统,它管理文件和目录可以超越时间。一组文件存放在中心版本库,这个版本库很像一个普通的文件服务器,只是它可以记录每一次文件和目录的修改,这便使你可以取得数据以前的版本,从而可以检查所作的更改。

从这个方面看,许多人把版本控制系统当作一种“时间机器”。

Subversion可以通过网络访问它的版本库,从而使用户可以在不同的电脑上使用。一定程度上可以说,允许用户在各自的地方修改同一份数据是促进协作。

进展可能非常的迅速,并没有一个所有的改变都会取得效果的通道,由于所有的工作都有历史版本,你不必担心由于失去某个通道而影响质量,如果存在不正确的改变,只要取消改变。

一些版本控制系统也是软件配置管理(SCM)系统,这种系统经过特定的精巧设计来管理源代码,有许多关于软件开发的特性—本身理解编程语言、或者提供构建程序的工具。

然而,Subversion不是这样一个系统,它是一个通用系统,可以管理任何类型的文件集,对你这可能是源代码—对别人,可能是一个货物清单或者是数字电影。

Subversion的历史早在 2000年,CollabNet, Inc.开始寻找CVS替代产品的开发人员,CollabNet提供了一个协作软件套件 SourceCast,它的一个组件是版本控制系统。

尽管 SourceCast在初始时使用CVS作为其版本控制系统,但是CVS的局限性在一开始就很明显,CollabNet知道迟早要找到一个更好的替代品。

遗憾的是,CVS成为了开源世界事实上的标准,因为没有更好的产品,至少是没有可以自由使用的。所以CollabNet决定写一个新的版本控制系统,建立在CVS思想之上的,但是修正其错误和不合理的特性。

2000年2月,他们联系 Open Source Development with CVS(Coriolis, 1999)的作者 Karl Fogel,并且询问他是否希望为这个新项目工作,巧合的是,当时Karl正在与朋友Jim Blandy 讨论设计一个新的版本控制系统。

在1995年,他们两个曾经开办一个提供CVS支持的公司Cyclic Software,尽管他们最终卖掉了公司,但还是天天使用CVS进行日常工作,在使用 CVS 时的挫折最终促使他们认真地去考虑如何管理标记版本的数据,而且他们当时不仅仅提出了“Subversion”这个名字,并且做出了Subversion版本库的基础设计。

所以当CollabNet提出邀请的时候,Karl 马上同意为这个项目工作,同时Jim也得到了他的雇主,RedHat 软件赞助他到这个项目并提供了一个宽松的时间。

CollabNet雇佣了 Kar l和 Ben Collins Sussman,详细的设计从三月开始,在Behlendorf 、CollabNet、Jason Robbins 和 Greg Stein(当时是一个独立开发者,活跃在WebDAV/DeltaV系统规范阶段)的恰当激励的帮助下,Subversion很快吸引了许多活跃的开发者,结果是许多有CVS经验的人们很乐于有机会为这个项目做些事情。

最初的设计小组固定在简单的目标上,他们不想在版本控制方法学中开垦处女地,他们只是希望修正CVS,他们决定Subversion匹配CVS的特性,保留相同的开发模型,但不复制CVS明显的缺陷。

尽管它不需要成为CVS的继任者,它也应该与CVS保持足够的相似性,使得CVS用户可以轻松的做出转换。

经过14个月的编码,2001年8月31日,Subversion 自己能够 “成为服务”了,开发者停止使用CVS保存 Subversion 的代码,而使用 Subversion 本身。

当CollabNet开始这个项目的时候,曾经资助了大量的工作(它为全职的Subversion开发者提供薪水),Subversion像许多开源项目一样,被一些激励知识界精英的宽松透明的规则支配着。

CollabNet的版权许可证完全符合Debian的自由软件方针,也就是说,任何人可以自由的下载,修改和重新发布,不需要经过 CollabNet 或其他人的允许。

Subversion 的特性当讨论 Subversion 为版本控制领域带来的特性的时候,通过学习它在CVS基础上所作的改进会是比较有效的方法。

如果你不熟悉CVS,你会不太明白所有的特性,如果你根本就不熟悉版本控制,你会瞪着眼无所适从,你最好首先阅读一下有关版本控制的其他介绍。

CVS 只记录单个文件的历史,但是Subversion实现了一个可以跟踪目录树更改的“虚拟”版本化文件系统,文件和目录都是有版本的。

因为 CVS 只记录单个文件的版本,对于拷贝和改名—这些文件经常发生的操作,会改变一个目录的内容—在 CVS 中并不支持。

在 CVS 里你也不可以用一个完全不同的文件覆盖原来的同名文件而又不继承原来文件的历史。

通过Subversion,你可以对文件或是目录进行增加、拷贝和改名操作,也可以新增一个具有干净历史的文件。

一系列的改动,要么全部提交到版本库,要么一个也不提交,这样可以让用户构建一个所要提交修改的逻辑块,防止部分修改提交到版本库。

每一个文件或目录都有一套属性—键和它们的值,你可以建立并存储任何键/值对,属性也是随时间的流逝而纳入版本控制的,很像文件的内容。

Subversion的架构俯视Subersion的设计,可以看出,一端是保存你所有纳入版本控制的数据的Subversion版本库,在另一端是你的 Subvesion客户端程序,管理着所有纳入版本控制数据的本地影射(叫做“工作拷贝”),在这两极之间是各种各样的版本库访问(RA)层,一些使用电脑网络通过网络服务器访问版本库,一些则绕过网络服务器直接访问版本库。

CollabNet 这个公司早在 2020 年和 XebiaLabs 进行了合并。

CVS 这个软件版本控制一直在 2010 的一个项目中还在使用。

后来好不容易让那个项目把版本控制从 CVS 转换到 SVN,谁知道没有过多久又需要从 SVN 转换到了 GIT。

不管怎么样,在大学毕业后的那几年,软件版本的控制一直用的是 CVS,也算是代表了青春的一段回忆。

还记得 CVS 那时候使用的logo是这条小鱼,不过很多年已经没有看到过这条小鱼了。

客户端那个时候使用的是这只小乌龟,现在软件开发的时候还是会安装这个小乌龟,只是这个小乌龟从 CVS 变成 SVN,然后变成了git。

不管软件行业的开发怎么变,当一个产品被市场慢慢淘汰的时候,可能连一个招呼都不会打。