BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 胡凯 关注 0 他的粉丝 发布于 2009年3月19日. 估计阅读时间: 2 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

又看到Zee哥的强文了,呵呵 by Dun David

怎么样,Zee,还记得我吗,呵呵

Re: 又看到Zee哥的强文了,呵呵 by see sai

p2p技术的?

Re: 又看到Zee哥的强文了,呵呵 by 胡 凯

是的,Mercurial可以借助点对点的方式交换修订

画图工具用的是什么呀? by 刘 平平

画图工具用的是什么呀?
图画得还不错哟!!!

branch不尽如人意 by Yang Kenny

好像Hg不支持在一个工作目录中开branch

Re: 画图工具用的是什么呀? by shao jim

office 2007

Re: branch不尽如人意 by 胡 凯

可以用Hg MQ来做到,但确实没有git的支持强大
好像Hg不支持在一个工作目录中开branch

本地库不是会越来越大吗 by Zeng SiYuan

那样本地库不是会越来越大吗

Git vs SVN by soft SG

个人觉得,当程序员的工作主要是离线式的,自由度要求颇高的,且对集中式的,频繁的CodeReview需求不高的,使用Git挺不错,只需熟记几个常用命令就可以,还可以离线工作。
但是对于团队开发,估计还是SVN较为合适。毕竟对于企业内部这种集中式管理环境,SVN的C/S结构天然适合,至少对于分布式版本管理工具而言的优势,对于这种集中开发的公司,就没有优势:
1、速度:内部网的速度问题可以忽略;
2、可靠:企业内部的SVN服务器,基本都是Raid结构,此外,每日增量备份导致出现问题的可能很小;

Re: 本地库不是会越来越大吗 by 胡 凯

你说的对,本地库是会变大,但变大的范围可以接受,我们自己项目的大小约为1.7G,相应的Mercurial本地库大小是450M。对于团队这更多的一种权衡吧,考虑到现在硬盘很便宜,牺牲一些硬盘空间换来稳定性和更好的效率还是比较划算的。
那样本地库不是会越来越大吗

Re: Git vs SVN by 胡 凯

>>>速度:内部网的速度问题可以忽略;
如果团队全在一地,速度问题是可以忽略的,但一个公司的团队如果分布在各个国家,特别是中国和美国,中国和印度之间的链接速度还是比较慢的。否则也不会有我在协同工作一节谈到的故事了。

>>>可靠:企业内部的SVN服务器,基本都是Raid结构,此外,每日增量备份导致出现问题的可能很小;
这个还是看企业的资源了吧,不可一概而论。

不过不论是Git还是Mercurial都提供了对svn的支持, gitSvn和hgSvn可以保持集中式的SVN环境的同时,在本地使用DVCS

个人觉得,当程序员的工作主要是离线式的,自由度要求颇高的,且对集中式的,频繁的CodeReview需求不高的,使用Git挺不错,只需熟记几个常用命令就可以,还可以离线工作。
但是对于团队开发,估计还是SVN较为合适。毕竟对于企业内部这种集中式管理环境,SVN的C/S结构天然适合,至少对于分布式版本管理工具而言的优势,对于这种集中开发的公司,就没有优势:
1、速度:内部网的速度问题可以忽略;
2、可靠:企业内部的SVN服务器,基本都是Raid结构,此外,每日增量备份导致出现问题的可能很小;

收费的版本控制软件Perforce也不错 by Zhong Jove

我们Team用的是这个,可以在各个地区建立服务器,本地程序员只需要连本地的服务器。服务器之间做proxy和备份
perforce的branch功能和revision管理很不错。一张revision graph很清楚的表示这个文件跨越多少分支已经被重构的历史

SVN加NetBeans本地历史,非常实用。 by _ moxie

SVN配合NetBeans的本地历史,非常实用。

请问GIT如何呢 by withyou gakaki

GITHUB的网速国内已经算是蛮快了 我觉得比CODEPLEX 啦 SF.NET google svn都要快

SVN的一个问题是速度慢 by Wu Gene

如果远程访问,做几次rebase和merge会要人命。

SVN对很多团队来说已经足够了,支持也很丰富。

Re: SVN的一个问题是速度慢 by 胡 凯

如果rebase操作缓慢,大都是由于网络连接比较缓慢,这样无论用什么版本管理工具都会慢,但DVCS的好处是有良好的离线支持, 减少不必要的网络调用。此外,merge操作在SVN上永远是要人命的。

就基本版本管理功能SVN足够了,然而SVN对于branch这一最普遍的开发实践支持太弱。对于帮助开发者有效率的开发和使用版本管理,SVN还离的很远。

如果远程访问,做几次rebase和merge会要人命。

SVN对很多团队来说已经足够了,支持也很丰富。

Re: 请问GIT如何呢 by 胡 凯

Git也是非常好的版本管理工具,非常快,而且对于branch的支持也非常强大。但是它限制了开发者所使用的平台。

GITHUB的网速国内已经算是蛮快了 我觉得比CODEPLEX 啦 SF.NET google svn都要快

分布式版本管理工具非常适用于分布式开发团队 by Xiao Alex

我们的情况与作者的描述及其相似,我现在感到十分幸运的是,我的团队在一年多了前也决定使用mercurial。跨地域的网络问题与时差问题是分布式团队时常遇到而又十分头痛的两个主要问题,mercurial极大地减轻了我们在这方面的痛苦。如果你的团队也是一个分布式的开发团队,强烈建议你选择一个类似mercurial的工具;如果你的团队只是本地化的,其实svn也足够用了。

偶棉是分布式使用SVN耶~~~ by 天色 璎珞

蜡果。。如果公司不穷。人员又多。还推荐介个咩??
偶棉的情况是:
1 北京两百人,杭州三百人,零星人员在美国,各地的人会同时频繁修改同一套代码。
2 最大滴一个库目前26G,统共备份量400G,16万个版本,每天提交400多次。开发环境都在Linux下。
3 代码库需要和Bug库,权限工具,项目管理工具集成。换句话说每个上线,发布,回滚,故障,Bug要和历史代码对应。
4 网络靠VPN,备份靠双机,7天全量,10分钟增量。库后台不是用数据库存储滴。只有当修订版本树的数量超过64位机同一目录下的文件数限制,才会出现传说中的SVN崩溃。
性能嘛,用着还行啊,还行

Re: 请问GIT如何呢 by Dai Derek

Git can run on Linux, Windows, it's a extreme fast, stable and secure DVCS. I transfered my projects from SVN to Git 6 months ago. In projects with over 18 thousand files, check status or commit just spend only 1 second!

权限怎样解决? by King Steven

DVCS的权限问题一直是软肋。
楼主说到的SVN服务器崩溃,实在令人不解。。。

Re: 偶棉是分布式使用SVN耶~~~ by xu alux

其实这个情况Git应该更适合

Re: 权限怎样解决? by Daobing LI

git 一般每个子项目一个库,所以问题不大

Re: 权限怎样解决? by 胡 凯

这一章对于如何进行权限控制应该说的比较清楚了

hgbook.red-bean.com/hgbookch6.html#x10-1240006.5

Re: 偶棉是分布式使用SVN耶~~~ by 胡 凯

如果把所有的代码作为一个DVCS库,不说性能,单说硬盘空间可能都吃不消,所以这样的情况,个人觉得Perforce或者Subversion可能会比较合适。

Re: SVN的一个问题是速度慢 by Peng Arthur

不明白说的svn 对branch支持太弱具体指的是什么,svn branch/merge没觉得有什么不方便的

Re: SVN的一个问题是速度慢 by xuhao pro

去了解一下git吧,再回来用svn就会发现很不方便了。

Re: branch不尽如人意 by Wu Willie

Hg 有許多外掛可以使用,其中內建的 bookmarks 以及 task extension 使用上與 git 的 local branch 相去不遠。

現在 Hg 的開發社群在討論要如何讓 bookmarks 的紀錄也可以經由 push / pull 來傳遞,加上 partial clone 很可能會於 1.4 版整合進來,我是很看好它的。

Git 功能的確很強大,但我覺得 Hg 也不遑多讓就是,各有優缺點。

多个团队异地开发考虑Mercurial,集中开发考虑SVN,毕竟内网速度不会成为问题 by Tarzan Wang Tarzan Wang

多个团队异地开发考虑Mercurial,集中开发考虑SVN,毕竟内网速度不会成为问题

Re: Git vs SVN by Tarzan Wang Tarzan Wang

多个团队异地开发考虑Mercurial,集中开发考虑SVN,毕竟内网速度不会成为问题

有道理,但是必要性上有待探讨 by ha lla

现在团队中,svn服务器放在英国,使用VPN连接,速度确实慢了点,但是考虑到,svn提交后的自动编译和测试服务器,并且由于时差,每天白天这里提交代码,晚上紧接着就是英国,每天都执行分支合并,似乎不现实。

Re: 多个团队异地开发考虑Mercurial,集中开发考虑SVN,毕竟内网速度不会成为问题 by cheng wind

对于多个团队异地的情况, 我们用svn mirror解决网速的问题,提交的时候向main server提交(提交的数据量都比较小,所以网速慢点影响不大),从本地mirror check out。麻烦之处是要自己做main和mirror的switch。而且mirror也起到一个备份的作用。

Git呢? by hack fire

为什么没有选择使用Git呢?
Git也可以在多个平台下运行啊。
Mercurial的优势在哪里呢,能否补充介绍下?

Re: Git呢? by Mao Sheng

Git当然是目前DVCS界最厉害的啦,功能强大,只是Windows下老是MinGW的preview,如果你不在乎用这个+TortoiseGit很不错。

不过我个人更喜欢hg,而且自身的文档也清晰,概念比较少,培训组员蛮容易的。当然我不是说这个比Git强,纯粹是喜好问题。

bzr也不错,那个号称自己的merge是最强的,当然,也有人挑刺过。

其实作者可能不知道有svn multisite,类似于cc multisite但优于cc multisite by Jesse Liu

非常适合跨地域的并行开发,省去了转换新工具的cost。dcvs比较适合个人和小组,在团队协同和企业开发还非常不完备。

是否笔误了? by Zhu Michael

"即便中央仓库完全损毁,所造成的损失也非常有限,避免了使用CVCS时将“所有鸡蛋放在一个篮子里”的风险。"

此处,CVCS是不是应该换成SVN?

Re: 是否笔误了? by Han Andy

"即便中央仓库完全损毁,所造成的损失也非常有限,避免了使用CVCS时将“所有鸡蛋放在一个篮子里”的风险。"

此处,CVCS是不是应该换成SVN?

没错的,svn就是一种CVCS。

Re: 收费的版本控制软件Perforce也不错 by Dou David

changelist这个功能也很不错!

Re: 请问GIT如何呢 by 鲜于 海平

springside 用git管理

白衣 推荐用smartgit客户端

Mecurial服务器的管理与Fork Pull Request by 简 茂仰

DVCS最近这几年真的很火红, 国外GitHub, BitBucket都是在这股DVCS的潮流下所崛起的开放源码网站, 但是在如果要架设在企业内部支持上百人的Mercurial服务器要如何管理?? 帐号, 库的权限要如何管理? 分支或是Fork/Pull request要如何管理(GitHub最为成功的功能就是可以参加开放源码的开发者支援Fork与Pull request).

DVCS虽然是分散式, 但是最终还是需要一台服务器来做代码的集成管理, DVCS虽然开分支很方便, 但是仅限于个人分支方便, 如果是团队有一部分成员要开发满足某个客户的需求, 局端分支管理并不容易, 这时候采用GitHub的Fork与Pull request策略是不错的选择.

如果您有以上需求, 可以参考CodeBeamer, CodeBeamer支持以下功能
1. Mercurial/Git库的建立与管理
2. 程序员的权限管理
3. Fork/Pull request, Pull request更可以让您支持审核流程与Master合并管理
CodeBeamer不仅支持Mercurial/Git库的管理, 也支持工作追踪与瑕疵追踪, 可以方便与Git/Mercurial集成, 有兴趣可以到我们网站参考参考

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

40 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT