像Mercurial这样使用分布式源代码控制对一个团队来说是否值得?

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

• hg commit :非常快,因此您将倾向于进行比Subversion更细粒度的提交。在Mercurial中,commit也是真正原子的,因为我们没有 mixed revisions . 我认为这是一个优势,但人们显然不同意。
• hg tag :指向历史记录中的特定点,而不是 /tags . Subversion标签的问题是,副本可能与 /trunk 看了具体的修订。Subversion实际上没有内置的标记,在模拟它们的同时,可能会以Mercurial中无法做到的方式搞砸。

hg bisect . 您可以使用它来查找出现特定错误的第一次修订。它的工作原理是二进制搜索,在每一步中,你将搜索间隔减半。你当然也可以用Subversion来实现这一点,但是没有对它的内置支持,而且速度会慢一些,因为你需要通过网络联系服务器。

这个 record extension 是Mercurial的另一个非常好的特性。它允许您只提交文件中的一些修改。这很好,因为它允许您进行小型的、自包含的提交。

几乎任何东西都比使用Subversion更好,我喜欢Mercurial(hg)和Darcs,但我最喜欢的仍然是 Fossil 对于个人项目(以及共享)。每个存储库有一个二进制文件和一个文件,可以很容易地跟踪我的工作,方便地备份它,方便地移动它,等等。此外,内置的wiki允许我将我的头脑风暴与我的源代码保持在一起,签入我的文档(生成的或以其他方式生成的)并通过内置服务器访问它的能力将我所有的工作放在一个地方,而内置的问题跟踪器使我能够保留我已经完成的工作或将来需要完成的工作的运行历史。

我强烈建议你读书 hginit

是的。尽管mercurial是“分布式”的,但我认为它对于一个单独的开发人员来说特别好。您可以获得与SVN类似的特性(加上许多其他特性),但总的来说,它们工作得更好更快。存储库的设置、备份和维护要容易得多。它被设计成允许许多单独的开发人员一起工作,所以在您需要与其他人一起工作之前,许多特性是有用的。

当我第一次换到hg的时候,总是有一种‘哦……比svn好得多’的感觉。在这一点上,我不会为我自己或一个小团队考虑VPN,只考虑水星、GIT或类似的DVCS。(我更喜欢水星)。

一个优点是,您可以脱机工作,比如在没有连接到源代码管理服务器的情况下在客户处编写代码。你多久做一次?

否则我就坚持颠覆。如果您需要它们,请学习如何正确使用发布和功能分支。没有理由因此搬到hg,即使 hginit 告诉你颠覆有多糟糕;)

我建议绝对使用版本控制进行单独开发。你用哪一个并不重要,SVN,Git,Hg等等。原因是它允许你在出现倒退的bug,代码丢失,损坏,当然还有分支和合并功能时回滚(你应该总是在一个分支中开发,只有在新特性/bug被完全测试时才与trunk合并),等等,所有这些东西(以及更多)如果没有版本控制系统,你将无法利用。