人们在这里看到Git,Mercurial和Bazaar的相对优势和劣势？
在考虑彼此之间以及针对SVN和Perforce等版本控制系统时,应该考虑哪些问题？
在规划从SVN迁移到这些分布式版本控制系统之一时,您会考虑哪些因素？
Git非常快,扩展性很好,并且对其概念非常透明.不利的一面是它有一个相对陡峭的学习曲线.可以使用Win32端口,但不是一流的公民.Git将哈希值作为版本号暴露给用户; 这提供了保证(因为单个散列总是指完全相同的内容;攻击者无法在未被检测到的情况下修改历史记录),但对用户来说可能很麻烦.Git具有跟踪文件内容的独特概念,即使这些内容在文件之间移动,并将文件视为第一级对象,但不跟踪目录.git的另一个问题是有很多操作(比如rebase))这使得修改历史记录变得容易(在某种意义上 - 哈希引用的内容永远不会改变,但对该哈希的引用可能会丢失); 一些纯粹主义者(包括我自己)不太喜欢这样.
Bazaar相当快(对于历史较浅的树很快,但目前的历史长度很差),并且易于学习熟悉传统SCM(CVS,SVN等)的命令行界面的人.Win32被其开发团队视为一流的目标.它具有适用于不同组件的可插拔架构,并经常替换其存储格式; 这允许他们引入新功能(例如更好地支持与基于不同概念的版本控制系统集成)并提高性能.Bazaar团队考虑目录跟踪并重命名支持一流的功能.虽然全局唯一的revision-id标识符可用于所有修订,树本地revnos(标准修订号,更类似于svn或其他更常规的SCM所使用的那些)用于代替内容哈希以识别修订.Bazaar支持"轻量级检出",其中历史记录保存在远程服务器上,而不是复制到本地系统,并在需要时通过网络自动引用; 目前,这在DSCM中是独一无二的.
两者都有某种形式的SVN集成; 但是,bzr-svn比git-svn更强大,主要是由于为此目的引入的后端格式修订.[更新,截至2014年:第三方商业产品SubGit提供SVN和Git之间的双向接口,其保真度与bzr-svn相当,并且更加精致; 当预算和许可限制允许时,我强烈建议将其用于git-svn.
我没有广泛使用Mercurial,因此无法对其进行详细评论 - 除非注意它与Git一样,具有内容哈希寻址用于修订; 也像Git一样,它不会将目录视为第一类对象(并且不能存储空目录).然而,除了Git之外,它比任何其他DSCM都快,并且具有比任何竞争对手更好的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一样,因为它是一个概念沉重的环境,而不是为了符合用户选择的工作流而构建的工具包 - 但我已经非常熟悉了它].
Ogre 3D项目的Steve Streeting刚刚(2009年9月28日)发表了一篇关于这个主题的博客文章,他对Git,Mercurial和Bazaar做了很好的比较.
最后,他找到了所有三个方面的优点和缺点,并没有明显的赢家.从好的方面来说,他提供了一个很棒的桌子来帮助你决定选择哪一个.
它是一个简短的阅读,我强烈推荐它.
人们在这里看到Git,Mercurial和Bazaar的相对优势和劣势？
在我看来,Git的优势在于它干净的底层设计和非常丰富的功能.我认为它也是对多分支存储库和管理分支繁重工作流的最佳支持.它非常快,并且存储库大小很小.
它有一些功能,这是有用的,但需要一些努力来使用它们.这些措施包括可视工作区和资源库数据库,它允许在更复杂的情况下,更好的合并决议,增量comitting,并与肮脏树comitting之间的中间分期ARA(指数); 检测使用相似启发式重命名和复制,而不是使用某种类型的文件ID的,效果很好的跟踪他们,并且允许怪(译注),它可以按照跨文件代码运动,不仅批发重命名.
它的一个缺点是MS Windows支持滞后而且不完整.另一种认为缺点是,它并不像有据可查的,例如水银,且较少的用户比竞争友好的,但它的变化.
在我看来,Mercurial的优势在于其良好的性能和小的存储库大小,以及良好的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和邮件列表的各种讨论,以及比较各种版本控制系统的博客文章和文章(其中一些在Git Wiki的GitComparison页面上列出).
InfoQ有一个很好的比较.
Mercurial和Bazaar在表面上非常相似.它们都提供基本的分布式版本控制,如在离线提交和合并多个分支时,都是用python编写的,并且都比git慢.一旦你深入研究代码,就会有很多不同之处,但是,对于日常的日常任务,它们实际上是相同的,尽管Mercurial似乎有更多的动力.
Git,嗯,不适合没有经验的人.它比Mercurial和Bazaar快得多,并且是为了管理Linux内核而编写的.它是三者中最快的,也是三者中最强大的,相当大的余地.Git的日志和提交操作工具是无与伦比的.然而,它也是使用最复杂和最危险的.丢失提交或破坏存储库非常容易,特别是如果你不理解git的内部工作原理.
看一下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/)
Sun对git,Mercurial和Bazaar进行了评估,作为替代Solaris代码库的Sun Teamware VCS的候选者.我发现它非常有趣.
京公网安备 11010802040832号 | 京ICP备19059560号-6 