对于一个团队来说，使用像 Mercurial 这样的分布式源代码控制是否值得？答案

【问题标题】：Is using distributed source control like Mercurial worthwhile for a team of one?对于一个团队来说，使用像 Mercurial 这样的分布式源代码控制是否值得？
【发布时间】：2010-03-15 10:55:45
【问题描述】：

我目前为我的单人软件公司使用 Subversion。是否值得搬到 Hg (Mercurial)？还是只有多人团队才能实现这些好处？

【问题讨论】：

标签： svn version-control mercurial dvcs

【解决方案1】：

我认为这是值得的，即使对于一个人来说——但我有点偏见，因为我是一个 Mercurial 开发人员 :-) 即使你从不分支和合并，Mercurial 是一个更好的 Subversion，用于提交等基本操作和标签：

hg commit: 非常快，所以你会倾向于进行比 Subversion 更细粒度的提交。由于我们没有mixed revisions，因此在 Mercurial 中提交也是真正原子的。我认为这是一种优势，但人们可能在这里显然不同意。
hg tag：指向历史中的特定点，而不是/tags下的副本。 Subversion 标签的问题在于，该副本可能与/trunk 查看特定修订的方式相同，也可能不同。 Subversion 确实没有内置标签，并且在模拟它们时，可能会以您在 Mercurial 中无法做到的方式搞砸。

因为 Mercurial 速度如此之快，人们使用它的方式与使用 Subversion 的方式不同。 hg bisect 就是一个很好的例子。您可以使用它来查找存在特定错误的第一个修订版。它通过二分搜索工作，您将每一步的搜索间隔减半。您当然也可以使用 Subversion 执行此操作，但没有内置支持，而且速度会较慢，因为您需要通过网络联系服务器。

record extension 是 Mercurial 的另一个非常好的功能。它允许您只提交文件中的一些修改。这很好，因为它可以让您进行小型且独立的提交。

【讨论】：

【解决方案2】：

根据我的经验，Git 和 Mercurial 目前更适合开源项目或小型团队或单人团队。所以，在你的情况下，我会推荐他们。 Subversion 更适合需要集中式 repo 和更细粒度访问控制的大型组织。

【讨论】：

【解决方案3】：

几乎任何事情都比使用 Subversion IMO 更好。我喜欢 Mercurial (hg) 和 Darcs，但到目前为止我最喜欢的仍然是 Fossil 用于个人项目（以及共享）。每个存储库使用一个二进制文件和一个文件，可以轻松跟踪我的工作，轻松备份它，轻松移动它等。此外，内置的 wiki 允许我将头脑风暴与我的资源一起保持，签入我的文档（生成的或其他方式）并通过内置服务器访问它的能力将我的所有工作放在一个地方，内置的问题跟踪器让我可以保存我工作过或需要做的事情的运行历史以后继续努力。

哦，Windows 在 Fossil 中并不像在我能说出的其他一些 DSCM 中那样是二等公民。（我在这里看着你，Git。）

【讨论】：

我专门询问 svn vs hg。
您的问题是“分布式源代码控制LIKE Mercurial”。如果您只想要 Mercurial，我建议您改写您的问题。

【解决方案4】：

我强烈建议您阅读hginit。这是 Hg 的一个很棒的教程，读完之后你有机会被卖掉:-)

【讨论】：

第一个颠覆颠覆的章节读起来可能会有些疑虑。我去过那里，看到了 - 三个开发人员试图重新整合一个分支整整一周。但这是我们的错，hg 也无法将其合并回来。应该学习如何正确使用发布和错误修复分支（也可以使用 hg btw！），然后 svn （几乎）和 hg 一样工作。
虽然 hginit 是目前最好的教程之一，但实际上它确实让我相信 mercurial 不是我们公司 SVN 的良好替代品。
我认为 hginit 缺少的一件事是“hg 分支”。它解释了标签和“通过克隆进行分支”，但没有解释如何使用“hg 分支”在 repo 中创建分支。也许我遗漏了一些东西，但是当我在服务器上运行 hg 时，我不能（或不想）必须在每次有人想要创建功能分支时创建服务器端克隆并配置权限。使用“hg 分支”在 repo 中创建分支似乎是使用 hg 的唯一可行的解决方案。但是 hginit 没有说明任何内容。

【解决方案5】：

是的。尽管 mercurial 被称为“分布式”，但我认为它对单独的开发人员特别有用。您可以获得与 SVN 类似的功能（以及许多其他功能），但总的来说它们工作得更好更快。存储库的设置、备份和维护要容易得多。它旨在让许多单独的开发人员一起工作，因此在您需要与其他人合作之前，许多功能都很有用。

我最喜欢的优点是简单的复制粘贴备份，以及为即时“沙盒”环境克隆存储库的能力。我有点杂乱无章，所以很高兴能够产生一个新环境，尝试一个想法并决定是否要将它集成到主代码库中。我可以做到这一点，而不会干扰我正在处理的原始任务。

当我第一次切换到 hg 时，我一直有一种“哦……这比 svn 好得多”的感觉。在这一点上，我不会为自己或小团队考虑 SVN，只会考虑 Mercurial、Git 或类似的 DVCS。（不过我更喜欢 mercurial）

【讨论】：

【解决方案6】：

一个优点是您可以离线工作，例如在没有连接到源代码控制服务器的情况下在客户处进行编码时。你多久这样做一次？

否则我只会坚持颠覆。如果您需要它们，请学习如何正确使用发布分支和功能分支。没有理由为此转向 hg，即使 hginit 告诉你颠覆有多糟糕；）

【讨论】：

Mercurial 的缺点：(1) 没有 svn:externals，(2) 您需要在本地保留存储库的完整副本 - 如果您想将多个项目保存在一个大存储库中，这很糟糕。第 1 点加剧了这个问题，这意味着项目之间很难共享代码。
#1 是我们决定不在工作中使用 hg 的原因之一。我有一个运行大约 50 个用户和大约相同数量的 repos 的颠覆服务器。svn:externals 无处不在。
@msemack：您的数字 (2) 实际上正是 DVCS 的最大优势之一，这正是它是 DVCS 而不仅仅是 VCS 的原因。上次我检查了像 Linux、OpenJDK、Python、OpenSolaris、Xorg 等超级项目，它们都使用 DVCS，并且大多数人喜欢开关。如果一个由 50 名开发人员组成的团队过度依赖不相关的项目，那么可能是时候想知道为什么 DVCS 可以为这个星球上最大的项目工作，以及为什么它不适用于 50 人的小团队。
@WizardOfOdds 你没有反驳第 2 点。您的所有示例都是单个项目，是一个孤立的“孤岛”。我们公司实际上有 100 多个项目，它们之间有相当数量的共享。所有这些项目都存在于一个仓库中。它们以分层树的形式组织。添加一个新项目是一个'svn mkdir sever'。 Mercurial 无法做到这一点。
DVCS 的另一个缺点（我最初没有提出）是它鼓励频繁提交，但仅限于本地存储库。这意味着您的所有工作仍在笔记本电脑的硬盘驱动器上，而不是在带有磁带备份的服务器的 RAID 阵列上。猜猜当您的硬盘崩溃或笔记本电脑被盗时会发生什么？对我来说，版本控制系统的最大优势在于它可以从本地机器上获取代码的主副本并将其放在安全的地方。

【解决方案7】：

我强烈建议您在单独开发时使用修订控制。您使用哪种方式并不重要，SVN、Git、Hg 等。原因是它允许您在出现回归错误、代码丢失、损坏以及分支和合并功能时进行回滚（您应该始终在分支中开发，并且仅在新功能/错误经过全面测试时才与主干合并）等等。所有这些（以及更多）如果没有版本控制系统，您将无法利用。

【讨论】：