Better CVS: Subversion

作者：Plasmabal
http://www.newzilla.org/2004/06/02/svn_intro/

前言

一个程序的生命周期, 可以用一个 '变' 字来说明. 正在发展时, 要加新程序代码; 写到差不多时, 要开始抓虫; 写好之后, 要加新功能. 有些改变只是几行而已, 而有些改变则是牵涉到好几个档案. 身为程序设计人员, 每天就是在应付这些变动. 如果一个程序大到无法由一个人维护时, 还得考虑多人同时修改的问题, 不然就是彼此互相踩到对方的脚.

人没有办法把每次的更动都详细地记下来, 正如很少有人能够正确地回答这个问题: 一年前的现在, 你在哪里? 跟谁见面? 作了什么? 谈了什么事? 而很不幸地, 常常在程序发展过程当中, 我们必须正确地知道某个变动在什么时候, 为了什么原因而加进去的, 而那次变动牵涉到哪些档案.

这些问题, 都可透过版本控制系统来获得有效的解决.

版本控制系统, 是一套用来管理档案变动的软件. 每作完一次的修改, 我们就向版本控制系统登录一次, 它便会纪录每次更动的档案, 并且让使用者输入一段注记, 作为本次修改的文字说明. 有了这些纪录, 我们便可以向它询问在什么时候作了什么样的更动, 并且显示当时输入的注记. 更好的是, 我们还可以要求将档案回复到某个曾经纪录过的状况. 想要将档案回复到前两次的更动前的状态吗? 没问题. 想要将档案回复到上个星期的状态吗? 没问题. 这些都是它可以做到的事.

CVS

目前有许多商业与开放源码的版本控制系统. 在开放源码界, 最早出现的, 大概就是 SCCS, 其后演变成为 RCS. 这两个都是以个别档案为基础来进行版本控制. 后来就有了 CVS 的出现, 它架构在 RCS 之上, 并且可以处理多个档案的送交 (也就是跟版本控制软件说, 我有这些档案更动过了, 请记住这些更动). 虽然可以处理多个档案的送交, 但是实际上, 各个档案彼此是各不相关的. 也就是说, 想要知道跟某个档案的更动一起变更的档案有哪些, 除了去找是不是有相同的注记, 大概没有其它的办法.

CVS 也不支持档案更名. 也就是说, 如果我们想要变更某个档案的名称, 那么它以前所累樍的更动与批注就得丢弃. 它也不支持以目录为单位的变动, 所以要想回复某个时间的目录内容是不可能的.

虽然 CVS 的缺点不少, 不过重新发展一套版本控制系统相当地不容易, 而且 CVS 也足堪使用, 所以大家就这么将就下去.

Subversion 登场

但是, 现在我们有 Subversion -- 一套更好的 CVS! 它同样也是开放源码, 而且架构, 命令列程序界面等, 都刻意模仿 CVS, 为的就是要让习于 CVS 的使用者能够快速上手.

那么, Subversion 有哪些优于 CVS 的地方呢?

一致的使用者界面

就 CVS 来说, 同样一个选项, 位于子命令之前与之后的差别就个自代表了不同的意义, 在不同子命令下也常代表了不同的意义, 也因此需要花费许多时间在熟悉这些差异. Subversion 的选项经过仔细的设计, 同一个选项, 不管它下在指令列的哪里, 也不管在哪一个子命令下, 所代表意义一定都是相同的, 也因此可以快速熟悉指令的用法.

目录版本控制

在 CVS 中, 一个目录是没有版本历程的. 假如原本一个名为 doc/ 的目录, 在经过一段时间之后, 发现它应该要称为 manual/ 比较恰当, 此时我们只能建立一个新 manual/, 把 doc/ 目录下的档案复制过去, 把 manual/ 下的档案新增至 CVS 系统中, 再把 doc/ 删除. 而且必须注意的是, 在档案的复制与删除的过程当中, 我们也同样地遗失了这些档案的历史历程. 版本控制最主要的资料就这么丢掉了!

但是在 Subversion 中, 目录跟档案同样都是纳入版本控制之中. 也就是说, 我们可以随时要求 Subversion 将某个档案回复到某个时间点的状态, 也可以对目录进行更名的动作.

不可分割的送交

在 CVS 中, 虽然我们可同时对复数档案进行送交, 但是 CVS 并不保证一次的送交是不可分割的. 也就是说, 如果我们同时对三个档案进行送交, 但是在第二个档案时发生意外状况 (例如档案有冲突, 或是网络断线), 此时 CVS 系统中会有送来的第一个档案的更动, 但是没有第二个与第三个的. CVS 系统里的档案就变成一个与我们预期不一致的状况!

Subversion 的送交就没有上述的问题. 也就是说, 送交的结果, 不是全都进系统, 就是全都没有进系统, 不会只有一部份进系统的状况.

更佳的二进制数据处理

CVS 虽然号称可以处理二进制的资料 (例如图形文件, Microsoft Word 档案), 但是需要使用者特别设定, 而使用者 常常 忘记. 再加上 CVS 会主动更动档案内容, 如列尾符号与关键词展开的功能, 以至于常常在需要将档案回复至过去的状况时, 才发现档案变得无法读取了. 再者, CVS 的档案内容差异算法几乎无法处理二进制档案, 以致于在储存档案上, 需要耗费大量的空间.

Subversion 对上述问题的处理方法有二. 首先, 它不主动更动档案内容, 除非使用者加上这样的设定. 再者, 它使用可适用于文字与二进制资料的内容差异算法, 在档案储存上, 文字与二进制资料都具有相同的优势. 现在, 不只是文字资料适合置于版本控制系统中, 连二进制资料也可以很方便地放进来.

高效率的分支与标记

我们可以对已纳入版本控制系统的档案进行标记, 也就是赋与它们一个易记的文字, 日后便可以利用这个易记的文字, 将这些档案回复到某个特定的状态. 但是 CVS 必须对每一个档案加上这样的标记, 档案愈多, 耗时愈久.

在 Subversion 系统, 标记是以目录的副本的方式建立的, 而副本是以类似链接的方式来建立. 也就是说, 不管牵涉的目录与档案有多少, 它所花费的时间都是固定的, 不会因为档案愈多而耗时愈久.

CVS 最为人所垢病的缺点, 就是它的分支功能相当难以使用. 但是在实际上运用时, 分支功能可以为使用人员增加不少便利. 像是可以藉由使用分支, 将程序代码隔离开来, 让发展人员可以进行大规模更动的同时, 还能让维护人员进行维护. 而 Subversion 的分支, 亦是以目录的副本来实作的, 在观念上更容易学习, 使用起来也更方便.

Subversion 的缺点

但是 Subversion 亦不全然没有缺点, 它毕章还是一个刚开始发展的系统, 仍然存在一些不易使用的地方.

档案保留

我们无法取得 Subversion 档案的独占编辑权. 这是因为 Subversion 的工作模式, 是让各个工作的人取得工作复本, 各自编辑后, 再于送交时进行合并. 不过有的时候, 我们还是得要先取得档案的独占编辑权, 像是在编辑图形文件. 此时, 由一个人统一对某个档案进行编辑, 要比事后合并要简单地多了.

合并点

当一个项目开始产生分支时, 常常我们得先将目前分支的更动合并至主发展线, 这些被合并的更动, 就称为合并点. Subversion 并不会记住分支已经采用了哪些合并点, 也就是说, 如果在合并更动之后, 在合并的地方又有了更动, 日后当分支发展完毕, 整个分支的更动需要合并至主发展线时, 由于系统不会记得已采用了哪些更动, 而已合并的地方又更动过, 就会造成同一个更动被合并两次, 此时后来的更动几乎可以肯定会造成档案的冲突, 必须由使用者进行排解. 如果系统能够记得合并点的话, 已采用的合并点就毋需再采用, 也就可以减少使用者必须手动进行冲突排解的次数.

档案版本

在 Subversion 中, 版本号码是整个系统共享的. 这个意思就是说, 如果一个项目的档案因修改而有版号的更动, 那么所有档案的版号都会跟着更动. 这对由 CVS 移转过来的使用者是最难以接受的, 需要花一点时间习惯.

但是, 在这种全域版号下, 我们无法很简单地回答这样的问题: 某个档案的第一个版本长什么样? 在目前最新版的前两个版本作了什么更动? 你知道, 有些时候, 我们就是需要像这样的功能.

I18N, L10N

虽然 Subversion 本身架构支持 Unicode, 不过使用者界面还是使用纯英文的环境. 对于多国语言的支持仍有一段路途要走.

结语

以上简单介绍了 Subversion 与 CVS 的优缺点评比. 虽然 Subversion 才开始发展三年, 直到今年才进入 1.0 版, 但是它所提供的便利性与功能性, 已经凌驾于 CVS 之上. 目前尚有不足的功能, 在活跃的开发团队的手中, 必定能很快地加上去. 有兴趣的读者现在就赶快加入使用 Subversion 的行列吧!