it-swarm.cn

Git,Mercurial和Bazaar的相对优势和劣势是什么?

人们在这里看到Git,Mercurial和Bazaar的相对优势和劣势?

在考虑彼此之间以及针对SVN和Perforce等版本控制系统时,应该考虑哪些问题?

在规划从SVN迁移到这些分布式版本控制系统之一时,您会考虑哪些因素?

135
Jordan Dea-Mattson

Git非常快,扩展性很好,并且对其概念非常透明。不利的一面是它有一个相对陡峭的学习曲线。可以使用Win32端口,但不是一流的公民。 Git将哈希值作为版本号暴露给用户;这提供了保证(因为单个散列总是指完全相同的内容;攻击者无法在未被检测到的情况下修改历史记录),但对用户来说可能很麻烦。 Git具有跟踪文件内容的独特概念,即使这些内容在文件之间移动,并将文件视为第一级对象,但不跟踪目录。 git的另一个问题是有很多操作(比如 变基)这使得修改历史记录变得容易(在某种意义上 - 哈希引用的内容永远不会改变,但对该哈希的引用可能会丢失);一些纯粹主义者(包括我自己)不太喜欢这样。

Bazaar相当快(对于历史较浅的树很快,但目前的历史长度很差),并且易于学习熟悉传统SCM(CVS,SVN等)的命令行界面的人。 Win32被其开发团队视为一流的目标。它具有适用于不同组件的可插拔架构,并经常替换其存储格式;这允许他们引入新功能(例如更好地支持与基于不同概念的版本控制系统集成)并提高性能。 Bazaar团队考虑目录跟踪并重命名支持一流的功能。虽然全局唯一版本ID标识符可用于所有修订,但使用树本地revnos(标准版本号,更类似于svn或其他更常规SCM使用的版本)来代替用于标识修订的内容哈希。 Bazaar支持“轻量级检出”,其中历史记录保存在远程服务器上,而不是复制到本地系统,并在需要时通过网络自动引用;目前,这在DSCM中是独一无二的。

两者都有某种形式的SVN集成;但是,bzr-svn比git-svn更强大,主要是由于为此目的引入的后端格式修订。 [更新,截至2014年:第三方商业产品SubGit提供SVN和Git之间的双向接口,其保真度与bzr-svn相当,并且更加精致;一世 非常 当预算和许可限制允许时,建议使用git-svn。

我没有广泛使用Mercurial,因此无法对其进行详细评论 - 除非注意它与Git一样,具有内容哈希寻址用于修订;也像Git一样,它不会将目录视为第一类对象(并且不能存储空目录)。然而,它比任何其他DSCM都快,除了Git,并且比其任何竞争对手都具有更好的IDE集成(特别是对于Eclipse)。鉴于其性能特征(仅略落后于Git)及其卓越的跨平台和IDE支持,Mercurial可能对拥有大量以win32为中心或IDE绑定成员的团队具有吸引力。

从SVN迁移的一个问题是SVN的GUI前端和IDE集成比任何分布式SCM更成熟。此外,如果您当前大量使用SVN预先提交脚本自动化(即在提交可以继续之前要求单元测试通过),您可能希望使用类似于 _ pqm _ 的工具来自动合并请求您的共享分支机构。

SVK是一个DSCM,它使用Subversion作为其后备存储,并且与SVN中心工具有很好的集成。但是,与任何其他主要DSCM(甚至是Darc)相比,它的性能和可扩展性都要大大降低,对于那些在历史长度或文件数量方面可能会变大的项目应该避免使用。

[关于作者:我使用Git和Perforce工作,Bazaar用于我的个人项目和嵌入式库;我雇主组织的其他部分大量使用Mercurial。在以前的生活中,我围绕SVN建立了大量的自动化;在此之前我有GNU Arch,BitKeeper,CVS等经验。 Git起初相当令人反感 - 它感觉像GNU Arch因为是一个概念沉重的环境,而不是为了符合用户选择的工作流而构建的工具包 - 但我从那以后对它感到很舒服]。

142
Charles Duffy

Ogre 3D项目的Steve Streeting刚刚(2009年9月28日)发表了一篇关于这个主题的博客文章,他做了一个伟大的,甚至交给了 比较Git,Mercurial和Bazaar

最后,他找到了所有三个人的优点和缺点,没有明显的赢家。从好的方面来说,他提供了一个很棒的桌子来帮助你决定选择哪一个。

alt text

它是一个简短的阅读,我强烈推荐它。

19
Michael La Voie

这里的人们认为Git,Mercurial和Bazaar的相对优势和劣势是什么?

在我看来 Git strength是它干净的底层设计和非常丰富的功能。我认为它也是对多分支存储库和管理分支繁重工作流的最佳支持。它非常快,并且存储库大小很小。

它有一些有用的功能,但需要付出一些努力才能使用它们。那些包括工作区和存储库数据库之间的可见中间分段ara(索引),这允许在更复杂的情况下更好地合并解决,增量编译和与脏树进行一致; 检测使用相似性启发式重命名和复制,而不是使用某种文件ID跟踪它们,这种方法效果很好,并且允许责备(注释)可以跟踪文件之间的代码移动而不仅仅是批量重命名。

它的一个缺点是MS Windows支持滞后而且不完整。另一个明显的缺点是,它没有像Mercurial那样有据可查,并且比竞争对手的用户友好性差,但它会发生变化。

在我看来 Mercurial strength在于其良好的MS Windows支持,其良好的性能和小的存储库大小。

在我看来,主要的缺点是本地分支(单个存储库中的多个分支)仍然是二等公民,并且以奇怪和复杂的方式实现标记。它处理文件重命名的方式也不是最理想的(但是这个迁移已经改变了)。 Mercurial不支持章鱼合并(有两个以上的父母)。

从我所听到的和阅读主要 Bazaar 优点是它可以轻松支持集中式工作流程(这也是不利的,集中式概念在不应该的地方可见),跟踪文件和目录的重命名。

它的主要缺点是具有长非线性历史的大型存储库的性能和存储库大小(至少对于不太大的存储库,性能得到改善),默认范例是每个存储库的一个牧场(尽管可以将其设置为共享数据)和集中的概念(但也从我听到的变化)。

Git是用C,Shell脚本和Perl编写的,并且是可编写脚本的; Mercurial是用C(核心,性能)和Python编写的,并提供扩展API; Bazaar是用Python编写的,并提供扩展API。


在考虑彼此之间以及针对SVN和Perforce等版本控制系统时,应考虑哪些问题?

Subversion(SVN),Perforce或ClearCase等版本控制系统是集中式版本控制系统。 Git,Mercurial,Bazaar(以及Darcs,Monotone和BitKeeper)是分布式版本控制系统。分布式版本控制系统允许更广泛的工作流程。他们允许使用“准备好时发布”。他们更好地支持分支和合并,以及分支繁重的工作流程。您不需要信任具有提交权限的人,以便能够以简单的方式从他们那里获得贡献。


在计划从SVN迁移到这些分布式版本控制系统之一时,您会考虑哪些因素?

您可能需要考虑的因素之一是支持与SVN的合作; Git有git-svn,Bazaar有bzr-svn,而Mercurial有hgsubversion扩展。

免责声明: 我是Git用户和小时间撰稿人,并观看(并参与)git邮件列表。我只知道Mercurial和Bazaar来自他们的文档,关于IRC和邮​​件列表的各种讨论,以及比较各种版本控制系统的博客文章和文章(其中一些列在 GitComparison Git Wiki页面)。

15
Jakub Narębski
14
Pat Notz

Mercurial和Bazaar在表面上非常相似。它们都提供基本的分布式版本控制,如在离线提交和合并多个分支时,都是用python编写的,并且都比git慢。一旦你深入研究代码,就会有很多不同之处,但是,对于日常的日常任务,它们实际上是相同的,尽管Mercurial似乎有更多的动力。

Git,嗯,不适合没有经验的人。它比Mercurial和Bazaar快得多,并且是为了管理Linux内核而编写的。这是三者中最快的,也是三者中最强大的,相当大的余地。 Git的日志和提交操作工具是无与伦比的。然而,它也是使用最复杂和最危险的。丢失提交或破坏存储库非常容易,特别是如果你不理解git的内部工作原理。

7
Herge

看一下Python开发人员最近做的比较: http://wiki.python.org/moin/DvcsComparison 。他们根据三个重要原因选择了Mercurial:

选择Mercurial是出于三个重要原因:

  • 根据一项小型调查,Python开发人员对使用Mercurial比对Bazaar或Git更感兴趣。
  • Mercurial是用Python编写的,它与python-dev倾向于“吃自己的狗食”一致。
  • Mercurial明显快于bzr(它比git慢,但差别要小得多)。
  • 对于SVN用户而言,Mercurial比Bazaar更容易学习。

(来自 http://www.python.org/dev/peps/pep-0374/

6
Martin Geisler

Sun对 gitMercurialBazaar 作为替代Sun Teamware VCS for Solaris代码库的候选者进行了评估。我发现它非常有趣。

5
DGentry

Bazaar中一个非常重要的缺失事物是cp。您不能拥有与SVN中相同历史记录的多个文件,例如参见 herehere 。如果你不打算使用cp,bzr是一个很好的(也很容易使用)替代svn。

2
Davide

我正在使用Bazaar一段时间,我很喜欢,但它只是较小的项目,即便如此,它也很慢。这么容易学习,但不是超级快。虽然这是非常x平台。

我目前使用Git,我喜欢它,因为版本1.6使得它在使用命令方面与其他VCS更相似。

我认为使用DVCS的经验主要区别在于:

  1. Git拥有最活跃的社区,看到有关Git的文章很常见
  2. GitHub 真的很摇滚。 Launchpad.net没问题,但没有像Github那样的乐趣
  3. Git的工作流程工具数量很多。它集成了整个地方。 Bzr有一些,但没有那么多或维护得很好。

总之,当我在DVCS上磨牙时,Bzr非常棒,但我现在对Git和Github非常满意。

2
sh1mmer

您的主要问题是这些是 分布式 SCM,因此需要对用户的思维方式进行一些改变。一旦人们习惯了这个想法,技术细节和使用模式就会落实到位,但不要低估最初的障碍,特别是在公司环境中。记住,所有问题都是人的问题。

1
David Plumpton

与Git相比,Bazaar更容易学习。 Git在github.com上有很好的支持。

我认为你应该尝试使用两者并决定哪个最适合你。

1
Rafał Rawicki

这是一个很大的问题,很大程度上依赖于上下文,这会花费你很多时间来输入这些小文本框之一。此外,当用于大多数程序员常用的东西时,所有这三个看起来都非常相似,所以即使理解差异也需要一些相当深奥的知识。

如果您可以将这些工具的分析打破到您有更具体问题的地步,您可能会得到更好的答案。

1
jfm3

人们在这里看到Git,Mercurial和Bazaar的相对优势和劣势?

这是一个非常开放的问题,接近火焰。

Git是最快的,但这三个都足够快。 Bazaar是最灵活的(它具有对SVN存储库的透明读写支持),并且非常关注用户体验。 Mercurial位于中间位置。

这三个系统都有很多粉丝。我个人是Bazaar的粉丝。

在考虑彼此之间以及针对SVN和Perforce等版本控制系统时,应该考虑哪些问题?

前者是分布式系统。后者是集中式系统。此外,Perforce是专有的,而所有其他的都是免费的 如同在语音中

集中式与分散型是比您在其类别中提到的任何系统更为重要的选择。

在规划从SVN迁移到这些分布式版本控制系统之一时,您会考虑哪些因素?

首先,缺乏TortoiseSVN的良好替代品。虽然Bazaar正在开发他们自己的 Tortoise变种 ,但截至2008年9月它还没有。

然后,培训关键人员如何使用分散系统将影响他们的工作。

最后,与系统的其余部分集成,例如问题跟踪器,夜间构建系统,自动测试系统等。

1
ddaa

ddaa.myopenid.com顺便提到了它,但我认为值得一提:Bazaar可以读取和写入远程SVN存储库。这意味着您可以在本地使用Bazaar作为概念验证,而团队的其他成员仍在使用Subversion。

编辑:几乎所有工具现在都有 某些 与SVN交互的方式,但我现在有个人经验git svn工作 非常 好。我已经使用了几个月,打嗝很少。

1
Hank Gay

Linus Torvalds在git上有很好的视频。他是Git的创造者,所以这就是他所宣传的内容,但在视频中他解释了SCM的分布以及为什么它们比集中式SCM更好。有很多比较git(Mercurial被认为是OK)和cvs/svn/perforce。观众也有关于迁移到分布式SCM的问题。

我发现这个材料具有启发性,我被卖给了分布式SCM。但尽管Linus的努力,我的选择是Mercurial。原因是bitbucket.org,我发现它比github更好(更慷慨)。

我需要在这里说一句警告:Linus有着相当激进的风格,我认为他想要好笑但我没有笑。除此之外,如果您不熟悉分布式SCM并考虑从SVN移动,那么视频非常棒。

http://www.youtube.com/watch?v=4XpnKHJAok8

1
k1udge

分布式版本控制系统(DVCS)解决了与集中式VCS不同的问题。比较它们就像比较锤子和螺丝刀。

集中式VCS 系统的设计意图是有一个真正的来源是有福的,因此是好的。所有开发人员从该源开始工作(checkout),然后添加(提交)他们的更改,然后变为类似的Blessed。 CVS,Subversion,ClearCase,Perforce,VisualSourceSafe和所有其他CVCS之间唯一真正的区别在于每个产品提供的工作流程,性能和集成。

分布式VCS 系统的设计意图是一个存储库与其他存储库一样好,并且从一个存储库到另一个存储库的合并只是另一种形式的通信。关于应该信任哪个存储库的任何语义值都是由进程从外部强加的,而不是由软件本身强加的。

使用一种类型或另一种类型之间的真正选择是组织 - 如果您的项目或组织想要集中控制,那么DVCS是非启动者。如果您的开发人员希望在全国/世界各地工作,没有安全的宽带连接到中央存储库,那么DVCS可能是您的救星。如果你需要两者,你就是fsck'd。

0
Craig Trader