这里的人们如何看待 Git、Mercurial 和 Bazaar 的相对优势和劣势？
在考虑它们中的每一个以及针对 SVN 和 Perforce 等版本控制系统时，应该考虑哪些问题？
在计划从 SVN 迁移到这些分布式版本控制系统之一时，您会考虑哪些因素？
问问题
17445 次
15 回答
147
Git 速度非常快，可扩展性非常好，并且其概念非常透明。不利的一面是它的学习曲线相对陡峭。可以使用 Win32 端口，但不是一等公民。Git 将哈希作为版本号公开给用户；这提供了保证（因为单个哈希始终引用完全相同的内容；攻击者无法在不被发现的情况下修改历史记录），但对用户来说可能很麻烦。Git 具有跟踪文件内容的独特概念，即使这些内容在文件之间移动，并将文件视为第一级对象，但不跟踪目录。git 的另一个问题是它有很多操作（例如rebase) 这使得修改历史变得容易（在某种意义上——哈希引用的内容永远不会改变，但对该哈希的引用可能会丢失）；一些纯粹主义者（包括我自己）不太喜欢这样。
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 一样，它不将目录视为一等对象（并且不能存储空目录）。然而，它比除 Git 之外的任何其他 DSCM 都快，并且比任何竞争对手都具有更好的 IDE 集成（尤其是 Eclipse）。鉴于其性能特征（仅略落后于 Git）及其卓越的跨平台和 IDE 支持，Mercurial 可能对拥有大量以 win32 为中心或受 IDE 约束的成员的团队具有吸引力。
从 SVN 迁移的一个问题是 SVN 的 GUI 前端和 IDE 集成比任何分布式 SCM 更成熟。此外，如果您目前大量使用 SVN 的预提交脚本自动化（即要求在提交可以继续之前通过单元测试），您可能希望使用类似于PQM的工具来自动合并对您的共享分支的请求。
SVK 是一个 DSCM，它使用 Subversion 作为其后备存储，并且与以 SVN 为中心的工具有很好的集成。但是，它的性能和可扩展性特征比任何其他主要的 DSCM（甚至 Darcs）都要差得多，因此应该避免用于在历史长度或文件数量方面可能会变得很大的项目。
[关于作者：我在工作中使用 Git 和 Perforce，在我的个人项目中使用 Bazaar 并作为嵌入式库；我雇主组织的其他部分大量使用 Mercurial。在前世，我围绕 SVN 构建了大量自动化；在此之前，我有使用 GNU Arch、BitKeeper、CVS 等的经验。Git 一开始很令人反感——感觉就像 GNU Arch，因为它是一个概念繁重的环境，而不是为符合用户选择的工作流程而构建的工具包——但从那以后我已经很适应了它]。
于 2008-09-16T22:05:28.603 回答
19
Ogre 3D 项目的 Steve Streeting 刚刚（2009 年 9 月 28 日）发表了一篇关于这个主题的博客文章，他在文章中对 Git、Mercurial 和 Bazaar 进行了很好的比较。
最后，他发现了三者的优势和劣势，没有明显的赢家。从好的方面来说，他提供了一张很棒的桌子来帮助你决定选择哪一张。
它是一个简短的阅读，我强烈推荐它。
于 2009-09-28T19:52:16.497 回答
16
这里的人们如何看待 Git、Mercurial 和 Bazaar 的相对优势和劣势？
在我看来， Git的优势在于其简洁的底层设计和非常丰富的功能集。它还具有我认为对多分支存储库和管理分支繁重的工作流的最佳支持。它非常快并且存储库大小很小。
它有一些有用的功能，但需要一些努力才能习惯它们。其中包括工作区和存储库数据库之间的可见中间暂存 ara（索引），它允许在更复杂的情况下更好地合并解决、增量提交和脏树提交；使用相似性启发式检测重命名和副本，而不是使用某种文件 ID 来跟踪它们，这种方法效果很好，并且允许指责（注释），它可以跟踪跨文件的代码移动，而不仅仅是批发重命名。
它的缺点之一是 MS Windows 支持滞后且不完整。另一个明显的缺点是它没有像 Mercurial 这样的文档那么完善，并且比竞争对手更不友好，但它会发生变化。
在我看来， 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页面上）中了解了 Mercurial 和 Bazaar。
于 2009-01-12T22:38:36.677 回答
8
Mercurial 和 Bazaar 在表面上非常相似。它们都提供基本的分布式版本控制，如离线提交和合并多个分支，都是用 python 编写的，而且都比 git 慢。一旦您深入研究代码，就会有许多不同之处，但是对于您的日常日常任务，它们实际上是相同的，尽管 Mercurial 似乎有更多的动力。
Git 不适合初学者。它比 Mercurial 和 Bazaar 都快得多，并且是为管理 Linux 内核而编写的。它是三者中最快的，也是三者中最强大的，相差很大。Git 的日志和提交操作工具是无与伦比的。但是，它也是最复杂和最危险的使用方法。丢失提交或破坏存储库非常容易，尤其是如果您不了解 git 的内部工作原理。
于 2008-09-16T22:11:09.963 回答
7
看看 Python 开发人员最近所做的比较：http ://wiki.python.org/moin/DvcsComparison 。他们基于三个重要原因选择 Mercurial：
选择 Mercurial 的原因有以下三个：
- 根据一项小型调查，Python 开发人员对使用 Mercurial 比对 Bazaar 或 Git 更感兴趣。
- Mercurial 是用 Python 编写的，这与 Python 开发者“吃自己的狗粮”的趋势一致。
- Mercurial 比 bzr 快得多（它比 git 慢，尽管差异要小得多）。
- 对于 SVN 用户来说，Mercurial 比 Bazaar 更容易学习。
于 2009-05-22T13:30:42.070 回答
2
我使用 Bazaar 有一段时间了，我非常喜欢它，但它只是较小的项目，即便如此它也很慢。如此容易学习，但不是超级快。虽然它是非常x平台的。
我目前使用我非常喜欢的 Git，因为 1.6 版使它在使用的命令方面与其他 VCS 更加相似。
我认为我使用 DVCS 的经验的主要区别是：
- Git 拥有最活跃的社区，经常看到关于 Git 的文章
- GitHub真的很棒。Launchpad.net 还可以，但没有比 Github 带来的快感
- Git 的工作流工具数量非常多。它集成在所有地方。Bzr 有一些，但没有那么多或维护得很好。
总之，当我开始使用 DVCS 时，Bzr 很棒，但我现在对 Git 和 Github 非常满意。
于 2009-01-29T20:24:03.060 回答
1
这是一个很大的问题，很大程度上取决于上下文，这将花费你很多时间来输入这些小文本框之一。此外，当用于大多数程序员通常做的事情时，所有这三个看起来都非常相似，因此即使理解这些差异也需要一些相当深奥的知识。
如果你能将这些工具的分析分解到你有更具体的问题的地步，你可能会得到更好的答案。
于 2008-09-16T21:57:40.383 回答
1
恕我直言，Bazaar 比 git 更容易学习。Git 在 github.com 上有很好的支持。
我认为您应该尝试同时使用两者并确定最适合您的。
于 2008-09-16T22:20:56.053 回答
1
这里的人们如何看待 Git、Mercurial 和 Bazaar 的相对优势和劣势？
这是一个非常开放的问题，接近于火焰诱饵。
Git 是最快的，但是这三个都足够快。Bazaar 是最灵活的（它对 SVN 存储库具有透明的读写支持）并且非常关心用户体验。Mercurial 处于中间位置。
这三个系统都有很多粉丝。我个人是集市迷。
在考虑它们中的每一个以及针对 SVN 和 Perforce 等版本控制系统时，应该考虑哪些问题？
前者是分布式系统。后者是集中式系统。此外，Perforce 是专有的，而所有其他的都是免费的，就像在语音中一样。
与您在其类别中提到的任何系统相比，集中式与分散式是一个更重要的选择。
在计划从 SVN 迁移到这些分布式版本控制系统之一时，您会考虑哪些因素？
首先，TortoiseSVN 缺乏好的替代品。尽管 Bazaar 正在开发他们自己的Tortoise 变体，但截至 2008 年 9 月还没有。
然后，培训关键人员使用去中心化系统将如何影响他们的工作。
最后，与系统的其他部分集成，例如问题跟踪器、夜间构建系统、自动化测试系统等。
于 2008-09-16T22:29:24.380 回答
1
ddaa.myopenid.com 顺便提到了它，但我认为还是值得一提：Bazaar 可以读写远程 SVN 存储库。这意味着您可以在本地使用 Bazaar 作为概念验证，而团队的其他成员仍在使用 Subversion。
编辑：现在几乎所有的工具都有某种与 SVN 交互的方式，但我现在有个人经验，git svn效果非常好。我已经使用它几个月了，几乎没有打嗝。
于 2008-09-17T09:50:42.107 回答
1
您的主要问题将是这些是分布式SCM，因此需要对用户的思维方式进行一些改变。一旦人们习惯了这个想法，技术细节和使用模式就会到位，但不要低估最初的障碍，尤其是在公司环境中。请记住，所有问题都是人的问题。
于 2008-09-18T10:17:20.737 回答
1
Linus Torvalds 在 git 上有很好的视频。他是 Git 的创建者，所以这就是他所宣传的，但在视频中他解释了分布式 SCM 是什么以及为什么它们比集中式 SCM 更好。有很多比较 git (mercurial 被认为是好的) 和 cvs/svn/perforce。观众也有关于迁移到分布式 SCM 的问题。
我发现这个材料很有启发性，我被卖给了分布式 SCM。但尽管 Linus 做出了努力，但我的选择是反复无常的。原因是 bitbucket.org，我发现它比 github 更好（更慷慨）。
在这里我要说一句警告：Linus 的风格相当激进，我认为他想搞笑但我没有笑。除此之外，如果您是分布式 SCM 的新手并考虑从 SVN 迁移，那么该视频非常棒。
于 2009-04-23T22:19:27.590 回答
0
分布式版本控制系统 (DVCS) 解决了与集中式 VCS 不同的问题。比较它们就像比较锤子和螺丝刀。
集中式 VCS系统的设计意图是存在一个受祝福的真正来源，因此是好的。所有开发人员都从该源工作（签出），然后添加（提交）他们的更改，然后这些更改变得类似 Blessed。CVS、Subversion、ClearCase、Perforce、VisualSourceSafe 和所有其他 CVCS 之间唯一真正的区别在于每个产品提供的工作流程、性能和集成。
分布式 VCS系统的设计意图是一个存储库与其他存储库一样好，并且从一个存储库合并到另一个存储库只是另一种通信形式。关于应该信任哪个存储库的任何语义值都是由进程从外部强加的，而不是由软件本身强加的。
使用一种类型或另一种类型的真正选择是组织性的——如果您的项目或组织想要集中控制，那么 DVCS 是不可能的。如果您的开发人员需要在全国/世界各地工作，而没有与中央存储库的安全宽带连接，那么 DVCS 可能是您的救星。如果你两者都需要，那你就完蛋了。
于 2008-09-16T22:15:41.730 回答