Git、 Mercurial 和 Bazaar 的优缺点是什么？

这是一个很大的问题，在很大程度上取决于上下文，要在这些小文本框中键入内容需要花费很多时间。而且，当用于大多数程序员所做的常规工作时，所有这三者看起来基本相似，因此即使理解这些差异也需要一些相当深奥的知识。

如果您能够将对这些工具的分析分解到您有更具体的问题的那一点，那么您可能会得到更好的答案。

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

Bazaar 相当快(对于历史较浅的树来说非常快，但是目前的历史长度很小) ，并且对于那些熟悉传统 SCM (CVS、 SVN 等)的命令行接口的人来说很容易学习。Win32被其开发团队认为是一流的目标。它为不同的组件提供了一个可插拔的架构，并且频繁地更换存储格式; 这允许它们引入新的特性(比如更好地支持基于不同概念的修订控制系统的集成)并提高性能。Bazaar 团队认为目录跟踪和重命名支持一流的功能。虽然全球唯一的修订 ID 标识符可用于所有修订，但是使用树-本地 Revnos (标准修订号，更类似于 svn 或其他更传统的 SCM 使用的修订号)代替内容散列来标识修订。Bazaar 支持“轻量级签出”，历史记录保存在远程服务器上，而不是复制到本地系统，并在需要时通过网络自动引用; 目前，这在 DSCM 中是独一无二的。

两者都提供了某种形式的 SVN 集成; 然而，bzr-SVN 比 git-SVN 强大得多，这主要是由于为此引入了后端格式修订。[更新，截至2014年: 第三方商业产品 SubGit 在 SVN 和 Git 之间提供了一个双向接口，在保真度上与 bzr-SVN 相当，并且更加完善; I < B > 强烈建议在预算和许可限制允许的情况下使用它，而不是 Git-SVN ]。

我没有广泛地使用过 Mercurial，所以不能详细地对它进行评论——除了注意到它，像 Git 一样，有用于修订的 content-hash 寻址; 也像 Git 一样，它不把目录当作一级对象(并且不能存储空目录)。然而，它比除 Git 之外的任何其他 DSCM 都要快，并且与其竞争对手相比，它具有更好的 IDE 集成(特别是对 Eclipse 而言)。考虑到 Mercurial 的性能特点(仅稍稍落后于 Git)及其卓越的跨平台和 IDE 支持，对于拥有大量以 win32为中心或受 IDE 约束的成员的团队来说，Mercurial 可能具有吸引力。

从 SVN 迁移的一个问题是，与任何分布式 SCM 相比，SVN 的 GUI 前端和 IDE 集成更加成熟。另外，如果您目前大量使用 SVN 的预提交脚本自动化(即。要求在提交之前通过单元测试) ，您可能需要使用类似于 PQM的工具来自动化对共享分支的合并请求。

SVK 是一个 DSCM，它使用 Subversion 作为后台存储，并且与以 SVN 为中心的工具有很好的集成。然而，与其他主要的 DSCM (甚至是 Darcs)相比，它的性能和可伸缩性特征差得多，对于那些在历史长度或文件数量方面可能增长很大的项目，应该避免使用它。

[关于作者: 我在工作中使用 Git 和 Perforce，在个人项目和嵌入式图书馆中使用 Bazaar; 我雇主组织的其他部分大量使用 Mercurial。在前世，我围绕 SVN 构建了大量的自动化; 在那之前，我有使用 GNU Arch、 BitKeeper、 CVS 和其他软件的经验。Git 一开始很让人讨厌——它感觉像是 GNU Arch，因为它是一个概念密集的环境，而不是为了迎合用户对工作流的选择而构建的工具包——但是后来我对它感到非常舒服]。

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

Git 不是给外行人看的。它比 Mercurial 和 Bazaar 都要快得多，而且是为了管理 Linux 内核而编写的。它是三辆车中速度最快的，也是三辆车中最强大的，以相当大的优势领先。Git 的日志和提交操作工具是无与伦比的。然而，它也是最复杂和最危险的使用。丢失一个提交或者毁掉一个存储库是非常容易的，特别是如果您不理解 git 的内部工作原理的话。

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

集中式 VCS 系统的设计意图是有一个真正的源头是被祝福的，因此是好的。所有开发人员都从这个源代码开始工作(签出) ，然后添加(提交)他们的更改，这些更改也会变得类似的“祝福”。CVS、 Subversion、 ClearCase、 Perforce、 VisualSourceSafe 和所有其他 CVCSes 之间唯一真正的区别在于每个产品提供的工作流、性能和集成。

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

在使用这种或那种类型之间的真正选择是组织化的——如果您的项目或组织想要集中控制，那么 DVCS 是不可能的。如果您的开发人员需要在全国/全世界范围内工作，没有安全的宽带连接到中央存储库，那么 DVCS 可能是您的救星。如果你两样都需要，你就死定了。

恕我直言，集市比饭桶容易学。 Git 在 github.com 上有很好的支持。

我认为你应该试着两者都用，然后决定哪一个最适合你。

这里的人们认为 Git、 Mercurial 和 Bazaar 的优缺点是什么？

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

Git 是最快的，但是三个都足够快。Bazaar 是最灵活的(它对 SVN 存储库提供透明的读写支持) ，并且非常关心用户体验。Mercurial 介于两者之间。

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

在考虑它们彼此之间的关系以及与版本控制系统(如 SVN 和 Perforce)的关系时，应该考虑哪些问题？

前者是分布式系统。后者是集中式系统。此外，Perforce 是专有的，而其他所有版本都是免费的 就像说话一样。

集中与分散是一个更重要的选择比任何系统，你提到在其类别。

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

首先，没有一个很好的 TortoiseSVN 替代品。虽然 Bazaar 正在开发他们自己的 乌龟变种，但是到2008年9月为止还没有完成。

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

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

Sun 对作为 Solaris 代码库的 Sun Teamware VCS 替代品的 饭桶、 反复无常和 集市进行了评估。我觉得很有趣。

Ddaa.myopenid.com 提到过，但是我认为还是值得一提的: Bazaar 可以读写到远程的 SVN 存储库。这意味着您可以在本地使用 Bazaar 作为概念验证，而团队的其他成员仍在使用 Subversion。

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

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

这里的人们认为 Git、 Mercurial 和 Bazaar 的优缺点是什么？

在我看来，饭桶的强项是它干净的底层设计和非常丰富的功能集。我认为它还对多分支存储库和管理分支繁多的工作流提供了最好的支持。它非常快，并且存储库大小很小。

它有一些有用的特性，但需要一些努力才能适应它们。其中包括 看得见工作区和存储库数据库之间的中间阶段 ara (索引) ，它允许在更复杂的情况下更好的合并解决方案，增量提交，以及使用脏树提交; 探测重命名和拷贝使用相似启发式方法，而不是使用某种文件 ID 跟踪它们，这种方法工作得很好，并且允许指责(注释) ，它可以跟踪代码在文件之间的移动，而不仅仅是批量重命名。

它的缺点之一是，微软视窗支持滞后，并没有充分。另一个明显的缺点是，它没有像 Mercurial 那样被很好地记录下来，用户友好性也不如竞争对手，但是它改变了。

在我看来，反复无常的优势在于其良好的性能和较小的存储库大小，在其良好的微软视窗支持。

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

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

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

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 的 比较页面上)了解它们的。

一个非常重要的 失踪了事情在集市是 cp。您不能像在 SVN 中那样，让多个文件共享相同的历史记录，例如 给你和 给你。如果您不打算使用 cp，那么 bzr 是 svn 的一个很好的替代品(并且非常容易使用)。

我使用 Bazaar 有一段时间了，我非常喜欢它，但是它只是一些小项目，即使那样它也非常缓慢。学起来很容易，但不是很快。尽管它是非常 X 平台。

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

我认为我使用 DVCS 的主要不同之处在于:

1. Git 拥有最具活力的社区，关于 Git 的文章也很常见
2. GitHub 真的很棒。 Launchpad.net 还可以，但是没有什么能比得上 GitHub 带来的乐趣
3. 用于 Git 的工作流工具的数量非常多。到处都是。有一些是用于 Bzr 的，但是没有那么多，也没有维护得那么好。

Linus Torvalds 在 git 上有一个很好的视频。他是 Git 的创始人，所以这就是他所宣传的，但在视频中他解释了什么是分布式 SCM，以及为什么它们比集中式的更好。有大量的比较 git (mercurial 被认为是 OK)和 cvs/svn/perforce。听众还对迁移到分布式 SCM 提出了疑问。

我发现这个材料启发和我被卖给分布式供应链管理。但是尽管莱纳斯很努力，我的选择还是变幻莫测。原因是 bitbucket. org，我发现它比 github 更好(更慷慨)。

我需要在这里说一句警告的话: 莱纳斯有相当咄咄逼人的风格，我认为他想要有趣，但我没有笑。除此之外，如果你是分布式 SCM 的新手，并考虑从 SVN 移动，这个视频非常棒。

Http://www.youtube.com/watch?v=4xpnkhjaok8

看看 Python 开发人员最近进行的比较: http://wiki.python.org/moin/DvcsComparison。他们之所以选择 Mercurial，有三个重要原因:

之所以选择 Mercurial，有三个重要原因:

• 根据一项小型调查，Python 开发人员对使用 Mercurial 更感兴趣 而不是在巴扎或基特。
• Mercurial 是用 Python 编写的，这与 Python-dev“吃自己的狗粮”的倾向是一致的。
• Mercurial 明显比 bzr 快(它比 git 慢，尽管差别小得多)。
• 对于 SVN 用户来说，Mercurial 比 Bazaar 更容易学习。

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

食人魔3D 项目的史蒂夫 · 斯特里廷刚刚(2009年9月28日)发表了一篇关于这个话题的博客文章，在这篇文章中他做了一个很棒的甚至是手工的 Git、 Mercurial 和 Bazaar 的比较。

最后，他发现优势和弱点与所有三个，没有明确的赢家。从好的方面来说，他提供了一张很好的桌子来帮助你决定选择哪一个。

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