文章:为什么我们要放弃 Subversion

  • 胡凯

2009 年 3 月 18 日

话题:Java敏捷.NETRuby最佳实践DevOps语言 & 开发文化 & 方法

Subversion曾经是我们亲密无间的战友,但自 从一年前部分团队成员去了美国,我们和 Subversion 的关系就开始出现了裂痕,首先是将 Subversion 服务器架设在美国后,中国开发人员频繁 进行的一些操作变得非常缓慢,本来通过追溯代码历史便可找出原因的问题,却因为网速缓慢,导致开发者将大量的时间耗费在等待服务器响应,而不是分析问题 上。其次,由于缺乏 IT 基础设施方面的投资以及完善的备份策略,数次因为网络原因或者服务器宕机,导致团队无法从中国访问版本管理服务器,正常的提交、更 新操作都无法进行,最严重的是版本管理服务器曾经在发布之前出现故障,导致服务器上的数据不得不回滚到九天以前,给发布带来了很大的风险。

从现象上看,版本管理服务器不在本地是遭遇速度瓶颈的主要原因,本质却是由于版本管理工具不能很好的根据团队的规模和结构伸缩。对我们而言,比较理 想的版本管理解决方案是在中美两地架设服务器,加快各个操作的执行速度,服务器之间自动同步来平衡两地对于速度和代码集成的要求。然而采用 Subversion 作为版本管理工具,决定了服务器仅能架设在一地。SVK可以解决部分问题,但它的缺陷太多,操作起来非常不便。我们所面临的备份问题则是由于在 Subversion 的设计中,所有的元数据仅仅保存在服务器上,一 旦服务器出现意外,元数据所包含的宝贵信息便无从恢复。之前的教训让我们认识到如果采用 Subversion 作为版本管理工具,就不能仅仅乐观的假设服务 器不会出错,必须有详尽可行的备份计划,通过不断备份来规避风险。

Subversion 的这些天生缺陷让我们把目光投向了DVCS(分布式版本管理工具),在这个家族中,比较成熟的产品有GitMercurialBzr, 相比之下,由于 Mercurial 对 Linux,Mac 和 Windows 平台有良好的支持,支持通过 Web 方式访问代码库,并存在成熟的 IntelliJ、Eclipse 插件,最终成为了胜出者,时至今日,它已经在我们团队服役超过 1 年了,从 0.9.4 到 1.1.2,每一次版本的更新,都 让我们愈加喜欢这个设计精巧产品。那么较之 Subversion,Mercurial 究竟胜在哪里?

详细内容,请阅读全文为什么我们要放弃 Subversion

Java敏捷.NETRuby最佳实践DevOps语言 & 开发文化 & 方法