当我被同事或管理层强制执行时，以流行观点为依据时，我最有可能使用集中式版本控制系统。这是最有可能的情况。
有一些具体情况下，我会选择Subversion或Perforce而不是Mercurial。这些与特定功能有关。例如，将随机子目录视为自己的存储库的能力在某些情况下可能很有用。Perforce在检出时重新排列目录结构的能力也可能很有用。Perforce在处理大型二进制对象方面表现出色，这些对象用于游戏开发和其他类型的媒体工作，而Mercurial和Git目前都不是特别擅长处理这些事情。
但总体来说，除非是非常特殊的情况，否则我永远不会选择非分布式版本控制系统。我认为它们极其限制和约束我的工作流程。自从我了解了版本控制以来，我就对它们感到失望。从纯工作流程的角度来看，使用集中式版本控制系统所能完成的事情，在分布式版本控制系统中也能够实现。
Subversion是一个非常好的集中式版本控制系统。它是成熟的，并且有很好的支持工具，比如Trac。它的“每个快照一个版本”的功能非常出色，而“分支”只是一个“轻量级副本”。实际上，在遗留版本控制的背景下，使用更“脆弱”的语义（例如每个文件的版本号和它们自己的特殊性），Subversion非常出色。（我已经用了多年。）
话虽如此，我正在转向Mercurial。（我会考虑Git，但目前在Windows上Mercurial更成熟。）Tortoise-Hg远没有Tortoise-SVN成熟。然而，Mercurial和Git都是为合并而构建的。这是版本控制系统的根本问题。
使用Mercurial时，每个仓库都有所有内容。合并很简单。仓库本身就是一个“沙盒”，因此您无需具备“主干”和“分支”的“千里眼”，以及进行其他分支前规划。简言之，即使开发人员集中在一个命令结构中（滚动到“最终批准的Trunk”分支），开发团队也是通过分布式仓库来工作的。
摘要：Subversion是一个很好的模型，但非常集中。它是成熟的，具有成熟的工具，并与其他工具（如Trac）成熟地集成。Mercurial（和Git）是更好的模型，但提供与Subversion相同的“每个仓库快照只有一个版本”。工具（如Tortoise-Hg）不够成熟（与Trac的集成需要更多的工作），并且您在使用Mercurial时会略微不同思考（例如，分布式仓库是同步的），这提供了一些优势，但您应该真正以不同的方式来考虑问题（比使用Subversion时）。
我每天都使用两者。它们都很棒。当我们以更成熟的方式将Mercurial与Trac集成时，我会完全转向Mercurial。（不那么成熟的Tortoise-Hg不如Tortoise-Svn好，但我可以接受它。）
完全迁移到仅使用Mercurial可能需要一段时间（比如一两年的时间，因为Trac提供更好的本地Mercurial集成）。Mercurial和Subversion之间的导入/导出并不困难。在我们现有的代码库中，我们同时使用两者：中央“主干”是Subversion，并且本地更改存储在Mercurial中，最终回检入到Subversion中。它运行良好。当Mercurial的优点不是你会使用或适用于你的情况时。
