速来报名!AICon北京站鸿蒙专场~ 了解详情
写点什么

ThoughtWorks 开发人员最喜爱的分布式版本控制系统

  • 2010-04-11
  • 本文字数:1913 字

    阅读完需:约 6 分钟

Martin Fowler 在 ThoughtWorks 的软件开发邮件列表中做了一个调查,了解开发人员怎么看待一些版本控制系统(VCS)。他据此对主要的版本控制系统写了一篇评论文章,并对集中式和分布式系统进行了比较。

调查的结果如下:

工具

最佳

不错

有问题

危险

无意见

有效回复

赞成比例 %

git

65

19

1

复制代码
14

85

99%

Mercurial

33

27

2

复制代码
36

62

97%

Subversion

20

72

6

1

复制代码
99

93%

Bazaar

1

13

3

复制代码
80

17

82%

Perforce

1

26

16

1

54

44

61%

CVS

复制代码
14

59

11

15

84

17%

ClearCase

复制代码
3

14

41

41

58

5%

VSS

1

1

11

64

22

77

3%

TFS

复制代码
32

22

44

54

0%

参与者把 9 种版本控制系统进行分类:最佳、不错、有问题、危险、无意见,最后一个是说他们根本没有用过。“有效回复”是指去除“无意见”的所有其他回复,而“赞成比例 %”是指(最佳 + 不错)/ 有效回复的比例。

虽然调查的范围有限,只表明了 ThoughtWorks 公司内部的主观看法,但该结果或许也可以代表其他公司对版本控制系统的看法。

两个开源分布式版本控制系统, git Mercurial 赞成比例最高,均超过了 95%。开源集中式版本控制系统 Subversion ,赞同比例也很高,达到 93%。而排名最低的是商业系统:IBM 的 ClearCase ,微软的 VSS 和 TFS

所有的 99 个回复者都用过 Subversion,85 个用过 git,84 个用过 CVS,而使用过 Bazaar 的只有 17 个人。多达 77 个人使用过 VSS,但是其赞成比例只有 3%。

这些结果与老马最初关于版本控制系统的评论不谋而合。通过与 ThoughtWorks 员工及合作者的讨论,马丁福勒总结说大家普遍接受的版本控制系统有 3 种,也是值得推荐的:Subversion、git 和 Mercurial。这意味着你需要在集中式和分布式 VCS 之间选择。对老马来说,分布式 VCS 的好处是“给工作带来了许多灵活性,但如果使用不当,这些灵活性反而会比较危险”。Subversion 的好处是:

鼓励使用简单的中央仓库模型,不鼓励大规模使用分支。如果你像我的许多朋友那样,正在使用持续集成,这种模型相当好用。Subversion 是个绝佳选择。 虽然分布式 VCS 给了你很多灵活性,可以灵活管理工作流程,然而据我所知,多数人的工作模式仍然基于一个共享的主线仓库,这也可以给持续集成使用。虽然现代的 VCS 都有强大的工具合并不同人的变化,但仍然只能是文本合并。持续集成仍然需要语义一致性。所以虽然团队使用了分布式 VCS,但仍然会有中央式主仓库的想法。

老马进而对分布式 VCS 和集中式 VCS 做了对比:

  • 速度 - 由于没有本地仓库拷贝,Subversion 较慢,尤其是当服务器远在其他大洲时。
  • 连接 - 即使网络断掉,分布式 VCS 也能够使用。
  • 分支 - 分布式 VCS 鼓励使用分支:

分布式 VCS 鼓励为试验快速创建分支。你也可以在 Subversion 中创建分支,但它们对所有人可见,妨碍了大家这么做。与此类似,分布式 VCS 鼓励在工作中设置检查点:你可以向本地代码库签入没有完成的代码,它们可能测试不过,甚至编译不过。同样,Subversion 中你也可以在开发者分支中这样做,但由于这些分支是共享的,大家都不愿意这样做。

老马提到集中式 VCS 更擅长处理二进制文件:

特定情况下,即使整个团队已经熟练使用分布式 VCS,也最好选择 Subversion。这就是当使用二进制,VCS 无法合并的时候 - 比如 Word 文档或者幻灯片。此时需要使用悲观锁,只能有一个签出是可写的 - 这就需要一个集中式的系统。

老马对 ClearCase 和 TFS 的评价很低:

有两个 VCS 倍受批评:IBM 的 ClearCase 和微软的 TFS 。它们广受批评的原因之一是客户使用广泛,通常是公司政策强制使用。 …我尊敬的一些开发人员曾频繁使用这些产品,但是并不推荐使用。

VSS 被认为是最差的选择:

在结束不推荐的版本控制系统之前,我想说一下这个尤其糟糕的工具:Visual Source Safe,或者可以称之为:Visual Source Shredder(译注:shredder,粉碎机)。感谢上帝,它现在已经很少见了,但是如果你还在用它,我们强烈建议你换掉,就现在!它不但用起来非常痛苦,我还听说过多次数据仓库崩溃的故事,实在不能让人信任。

老马的看法比较主观,并没有比较它们的实际功能。文章 Better SCM Initiative 中对 28 种版本控制系统做了深度比较,但并没有排名,而是提供一些关键功能指标,包括:原子提交、文件和目录的移动或者重命名、移动或者重命名后的智能合并、文件和目录拷贝、能够只在一个目录工作、跟踪没有提交的变化、文档、部署的难易程度等等,这样用户可以自己决定哪个 VCS 最好。

Scott Chacon 写了个帖子为git 辩护,解释为什么他认为git 比Mercurial、Bazaar 或者SVN 更好:廉价的本地分支、一切都在本地、速度快、适用于任何工作流程,以及其他一些原因。

当然,每个开发人员或者团队都有自己喜欢的CVS。您最喜欢的是什么呢?您有没有高兴或者惨痛的经历与大家分享?

参见英文原文: ThoughtWorks’ Developers Favor Distributed Version Control Systems

2010-04-11 00:105076
用户头像

发布了 37 篇内容, 共 11.5 次阅读, 收获喜欢 5 次。

关注

评论

发布
暂无评论
发现更多内容

数据采集能力受限?企业数字化运营如何迈出第1步

易观大数据

以区块链为基础 通证经济是下一代互联网的数字经济

CECBC

区块链 落地应用

基于 grpc,protobuf搭建 server/client模型通信

是老郭啊

如何设计实现一个证书加密签名工具包

三尾鱼

troubleshoot之:用control+break解决线程死锁问题

程序那些事

Java JVM 死锁

你为什么还在用存储过程?

架构师修行之路

数据库设计 架构设计

从数据中台到AI中台,企业到底要建什么中台?

脑极体

HTTPS证书过期导致的故障

焦振清

运维 https SRE 服务故障 证书过期

LeetCode题解:24. 两两交换链表中的节点,递归,JavaScript,详细注释

Lee Chen

大前端 LeetCode

真正的勇士,会跨过六道裂谷,奔向云与AI的彼端

脑极体

Kafka处理请求的全流程解析

yes

kafka 面试 后端 消息队列 源码解析

区块链跃升各国创新战略

CECBC

新基建 国家战略 区块链标准

ARTS-week-2

saddamwilson

ARTS 打卡计划

踩坑记 | Flutter升级影响了NestedScrollView?

哈利迪

android

机器学习算法之——卷积神经网络(CNN)原理讲解

迈微AI研发社

学习 算法 卷积神经网络 CNN

JDK1.8新特性(七):默认方法,真香,开动!接口?我要升级!!

xcbeyond

接口 新特性 JDK1.8 默认方法 JDK1.8新特性

List 和 Map 的排序

一盐难进

Java

# spring boot自定义线程池进行异步调用

一盐难进

Java

区块链+收藏品,全球三种典型应用路径的差异化

CECBC

区块链 应用价值

Go: 互斥锁和饥饿

陈思敏捷

mutex Go 语言

原来你是这样的B+树

Java技术宝典

B+树

服务器与普通电脑的区别?

德胜网络-阳

多省市出台关于区块链人才引进的计划

CECBC

新基建 区块链技术

知路,然后智行远;懂行,所以万业兴

脑极体

2.1.2 类加载器的工作原理与自定义加载器 -《SSM深入解析与项目实战》

谙忆

DevOps 技术栈

柴锋

Linux DevOps 运维 敏捷 Shell

2.2.1 类反射 -《SSM深入解析与项目实战》

谙忆

数据库的乐观锁和悲观锁并非真实的锁

架构师修行之路

数据库 架构 乐观锁 悲观锁 分布式锁

ARTS Week8

丽子

机器学习算法之——K最近邻(k-Nearest Neighbor,KNN)分类算法原理讲解

迈微AI研发社

学习 算法 KNN K聚类

如何对 ElasticSearch 集群进行压力测试

白宦成

elasticsearch ELK Elastic Stack

ThoughtWorks开发人员最喜爱的分布式版本控制系统_Java_Abel Avram_InfoQ精选文章