svn - Git、Mercurial 和 Bazaar 的相对优势和劣势是什么？

Question

就目前而言，这个问题不适合我们的问答形式。我们希望答案得到事实、引用或专业知识的支持，但这个问题可能会引起辩论、争论、投票或扩展讨论。如果您觉得这个问题可以改进并可能重新打开，visit the help center为指导。




8年前关闭。




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

在考虑它们中的每一个并针对 SVN 和 Perforce 等版本控制系统时，应该考虑哪些问题？

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

Answer 1

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

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

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

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

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

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

[关于作者:我在工作中使用 Git 和 Perforce，在我的个人项目和嵌入式库中使用 Bazaar；我雇主组织的其他部分大量使用 Mercurial。在前世，我围绕 SVN 构建了大量自动化；在此之前，我有 GNU Arch、BitKeeper、CVS 等方面的经验。 Git 一开始很令人反感——感觉就像 GNU Arch，因为它是一个概念繁重的环境，而不是为符合用户选择的工作流程而构建的工具包——但从那时起我就非常适应了它]。