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

在相互考虑并针对诸如SVN和Perforce之类的版本控制系统进行考虑时，应考虑哪些问题？

在计划从SVN到这些分布式版本控制系统之一的迁移时，我们将考虑哪些因素？

解决方案

回答

这是一个很大的问题，在很大程度上取决于上下文，这将花费我们很多时间在这些小文本框中之一中键入内容。同样，当用于大多数程序员的常用内容时，所有这三种方法看起来都基本相似，因此，即使要了解差异，也需要一些相当深奥的知识。

如果我们可以将对这些工具的分析分解为更具体的问题，则可能会得到更好的答案。

回答

Git速度非常快，扩展性非常好，并且其概念非常透明。不利的一面是它的学习曲线相对陡峭。可以使用Win32端口，但不是一等公民。 Git向用户公开哈希作为版本号；这提供了保证(因为单个散列始终指的是完全相同的内容；攻击者无法在不被检测到的情况下修改历史记录)，但是对于用户而言可能很麻烦。 Git具有跟踪文件内容的独特概念，即使这些内容在文件之间移动并且将文件作为第一级对象查看，但不跟踪目录。 git的另一个问题是，它具有许多操作(例如<I> rebase)，使修改历史记录变得容易(从某种意义上说，哈希所引用的内容永远不会改变，但是对该哈希的引用可能会丢失)；一些纯粹主义者(包括我自己)不太喜欢。

Bazaar相当快(对于具有浅历史记录的树来说非常快，但是目前随着历史记录的长度扩展性很差)，并且对于熟悉传统SCM命令行界面(CVS，SVN等)的人来说易于学习。 Win32被其开发团队视为一流的目标。它具有用于不同组件的可插拔体系结构，并经常替换其存储格式。这使他们可以引入新功能(例如更好地支持与基于不同概念的修订控制系统的集成)并提高性能。 Bazaar团队认为目录跟踪和重命名支持一流的功能。尽管全局唯一的修订ID标识符可用于所有修订，但使用树形本地修订号(标准修订号，更类似于svn或者其他更常规的SCM所使用的修订号)代替内容散列来标识修订。 Bazaar支持"轻量结帐"，其中历史记录保存在远程服务器上，而不是复制到本地系统中，并在需要时通过网络自动引用。目前，这在DSCM中是唯一的。

两者都有某种形式的SVN集成。但是，bzr-svn比git-svn的功能要强大得多，这在很大程度上是由于为此目的引入了后端格式修订。 <I> [自2014年起更新：第三方商业产品SubGit在SVN和Git之间提供了双向接口，其保真度可与bzr-svn相提并论，并且更加精致；在预算和许可限制允许的情况下，我<B>强烈建议在git-svn上使用它。

我没有广泛使用Mercurial，因此无法对其进行详细评论-除非注意到它像Git一样，具有针对内容修订的内容哈希寻址；与Git一样，它也不会将目录视为一流对象(并且无法存储空目录)。但是，它比Git之外的任何其他DSCM都要快，并且IDE集成(尤其是Eclipse)要比其任何竞争对手都要好得多。鉴于其性能特征(仅略低于Git的性能)以及出色的跨平台和IDE支持，Mercurial可能对于拥有大量以win32为中心或者受IDE约束的成员的团队具有吸引力。

从SVN迁移的一个担心是，SVN的GUI前端和IDE集成比任何分布式SCM都更成熟。此外，如果我们当前大量使用SVN进行预提交脚本自动化(即要求在进行提交之前必须通过单元测试)，则可能要使用类似于PQM的工具来自动执行对共享分支的合并请求。

SVK是使用Subversion作为后备存储的DSCM，并且与以SVN为中心的工具具有很好的集成。但是，它的性能和可伸缩性特性比任何其他主要的DSCM(甚至是Darcs)都要差得多，因此对于历史长度或者文件数量可能会增大的项目，应避免使用它。

[关于作者：我使用Git和Perforce进行工作，使用Bazaar进行我的个人项目并作为嵌入式库；我的雇主组织的其他部门大量使用Mercurial。在以前的生活中，我围绕SVN构建了很多自动化功能。在此之前，我曾经在GNU Arch，BitKeeper，CVS和其他方面有经验。 Git一开始就很反感-感觉就像GNU Arch一样，它是一个概念繁重的环境，而不是为遵循用户选择的工作流而构建的工具包-但从那时起，我就对它感到非常满意。 。

回答

水星和集市在表面上非常相似。它们都提供基本的分布式版本控制，例如在脱机提交和合并多个分支中，它们都是用python编写的，并且都比git慢。深入研究代码后，会有很多差异，但是，对于日常的日常任务，它们实际上是相同的，尽管Mercurial似乎有更多的发展动力。

Git好吧，这不是针对没有经验的人。它比Mercurial和Bazaar都快得多，并且是为管理Linux内核而编写的。它是三者中最快的，也是三者中最强大的，相当可观。 Git的日志和提交操作工具无与伦比。但是，它也是最复杂和最危险的使用方式。丢失提交或者破坏存储库非常容易，尤其是如果我们不了解git的内部工作原理时。

回答

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

集中式VCS系统的设计意图是有一个真实的源头，这是有福的，因此是好源。所有开发人员都从该源工作(签出)，然后添加(提交)他们的更改，这些更改也同样受到了祝福。 CVS，Subversion，ClearCase，Perforce，VisualSourceSafe和所有其他CVCS之间的唯一真正区别在于每种产品提供的工作流程，性能和集成。

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

在使用一种类型或者另一种类型之间的真正选择是组织-如果项目或者组织需要集中控制，那么DVCS就不是启动器。如果希望开发人员可以在整个国家/世界上工作，而没有到中央存储库的安全宽带连接，那么DVCS可能是救星。如果两者都需要，我们会感到震惊。

回答

集市比IMHO更容易学习。
Git在github.com上有很好的支持。

我认为我们应该同时使用这两种方法，并确定最适合方法。

回答

What do folks here see as the relative strengths and weaknesses of Git, Mercurial, and Bazaar?

这是一个非常开放的问题，与烈火有关。

Git是最快的，但是这三个都足够快。 Bazaar是最灵活的(它对SVN存储库具有透明的读写支持)，并且非常关心用户体验。水星在中间。

这三个系统都有很多粉丝。我个人是义卖市场的粉丝。

In considering each of them with one another and against version control systems like SVN and Perforce, what issues should be considered?

前者是分布式系统。后者是集中式系统。另外，Perforce是专有的，而其他所有语言都是免费的。

集中式与分散式的选择比我们在其类别中提到的任何系统都重要得多。

In planning a migration from SVN to one of these distributed version control systems, what factors would you consider?

首先，缺少TortoiseSVN的良好替代品。尽管Bazaar正在开发自己的Tortoise变体，但截至2008年9月，它尚不存在。

然后，对关键人员进行培训，使其了解如何使用去中心化系统将影响他们的工作。

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

回答

InfoQ有一个很好的比较。

回答

Sun对git，Mercurial和Bazaar进行了评估，以替代Solaris代码库的Sun Teamware VCS。我觉得这很有趣。

回答

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

编辑：几乎所有工具现在都具有与SVN交互的某种方式，但是我现在有个人经验，git svn效果非常好。我使用它已经有几个月了，几乎没有打h。

回答

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

回答

What do folks here see as the relative strengths and weaknesses of Git, Mercurial, and Bazaar?

在我看来，Git的优势在于其简洁的底层设计和非常丰富的功能集。我认为它也为多分支存储库和管理分支繁重的工作流提供了最佳支持。它非常快，并且存储库大小很小。

它具有一些有用的功能，但需要花费一些精力才能使用它们。其中包括工作区和存储库数据库之间的可见中间阶段ara(索引)，它可以在更复杂的情况下更好地合并解析，增量提交和使用脏树进行提交；使用相似性试探法检测重命名和副本，而不是使用某种文件ID来跟踪它们，这种方法效果很好，并且可以怪罪(注释)，这不仅可以跟踪整个文件中的代码移动，而且还可以跟踪批量文件名。

它的缺点之一是MS Windows支持滞后并且不完整。另一个可察觉的缺点是，它的记录不如Mercurial那样，并且不如竞争对手易用，但它会发生变化。

在我看来，Mercurial的优势在于其良好的性能和较小的存储库大小，以及对MS Windows的良好支持。

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

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

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

Git用C，shell脚本和Perl编写，并且可以编写脚本。 Mercurial用C(性能代表核心)和Python编写，并提供扩展API。 Bazaar用Python编写，并提供扩展API。

In considering each of them with one another and against version control systems like SVN and Perforce, what issues should be considered?

诸如Subversion(SVN)，Perforce或者ClearCase之类的版本控制系统是集中式版本控制系统。 Git，Mercurial，Bazaar(以及Darcs，Monotone和BitKeeper)是分布式版本控制系统。分布式版本控制系统允许更广泛的工作流。他们允许使用"准备就绪时发布"。他们对分支和合并以及繁重的工作流提供了更好的支持。我们无需信任具有提交访问权限的人员，便可以轻松地从他们那里获得捐款。

In planning a migration from SVN to one of these distributed version control systems, what factors would you consider?

我们可能要考虑的因素之一是对SVN吸引力的支持。 Git具有git-svn，Bazaar具有bzr-svn，Mercurial具有hgsubversion扩展名。

免责声明：我是Git用户和少量时间贡献者，并查看(并参与git邮件列表)。我仅从Mercurial和Bazaar的文档，关于IRC和邮件列表的各种讨论以及比较各种版本控制系统的博客文章和文章(其中有些列在Git Wiki的GitComparison页面上)中了解Mercurial和Bazaar。

回答

集市中一个非常重要的丢失内容是cp。我们不能像SVN中那样拥有多个共享相同历史记录的文件，请参见此处和此处的示例。如果我们不打算使用cp，则bzr是svn的绝佳替代品，并且非常易于使用。

回答

我使用Bazaar一段时间了，我很喜欢它，但那只是较小的项目，即使那样也很慢。如此简单易学，但不是超级快。它是非常x平台的。

我目前非常喜欢Git，因为1.6版在使用命令方面使其与其他VCS更加相似。

我认为我使用DVCS的主要区别在于：

• Git拥有最活跃的社区，通常会看到有关Git的文章
• GitHub真的很糟糕。 Launchpad.net可以，但是没有像Github的乐趣
• Git的工作流程工具数量众多。它已集成到各处。 Bzr有一些功能，但维护数量却很少或者保持得很好。

总而言之，当我在DVCS上学习时，Bzr很棒，但是现在我对Git和Github感到非常满意。

回答

Linus Torvalds在git上有很好的视频。他是Git的创建者，所以他要推广这一点，但是在视频中，他解释了什么是分布式SCM，以及为什么它们比集中式SCM更好。有很多比较git(可以认为使用Mercurial可以)和cvs / svn / perforce的比较。听众也有关于向分布式SCM迁移的问题。

我发现这种材料很有启发性，我被卖给了分布式SCM。但是，尽管莱纳斯(Linus)做出了努力，但我的选择还是富有挑战性的。原因是bitbucket.org，我发现它比github更好(更慷慨)。

我在这里要提个警告：莱纳斯(Linus)具有相当进取的风格，我认为他想变得有趣，但我没有笑。此外，如果我们是分布式SCM的新手，并考虑从SVN迁移，那么该视频非常棒。

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

回答

看看最近由Python开发人员进行的比较：http：//wiki.python.org/moin/DvcsComparison。他们基于以下三个重要原因选择了Mercurial：

The choice to go with Mercurial was made for three important reasons:
  
  
  According to a small survey, Python developers are more interested in using Mercurial
  than in Bazaar or Git.
  Mercurial is written in Python, which is congruent with the python-dev tendency to 'eat their own dogfood'.
  Mercurial is significantly faster than bzr (it's slower than git, though by a much smaller difference).
  Mercurial is easier to learn for SVN users than Bazaar.
  
  
  (from http://www.python.org/dev/peps/pep-0374/)

回答

Ogre 3D项目的Steve Streeting刚在(9/28/2009)上发布了有关该主题的博客条目，他在其中对Git，Mercurial和Bazaar进行了非常出色的对比。

最后，他发现了三者的优势和劣势，没有明显的获胜者。从好的方面来说，他给出了一个很好的表，可以决定该选择哪一个。

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