我已经在我的个人项目中使用Mercurial一段时间了，而且我很喜欢它。我的雇主正在考虑从CVS切换到SVN，但我想知道是否应该推动改用Mercurial（或其他DVCS）。
Mercurial的一个问题是它似乎是围绕着每个“项目”只有单个存储库的想法设计的。 在这个组织中，当前的CVS存储库中有许多不同的可执行文件、DLL和其他组件，按层次结构组织。 有很多通用的可重用组件，但也有一些客户特定的组件和客户特定的配置。 目前的构建过程通常会从CVS存储库中获取某些子树集。
如果我们从CVS迁移到Mercurial，最佳的存储库/存储库组织方式是什么？ 我们应该有一个包含所有内容的巨大的Mercurial存储库吗？ 如果不是，较小的存储库应该有多精细？ 我认为，如果他们必须从很多不同的地方拉取和推送更新，人们会觉得非常烦人，但如果他们必须拉/推整个公司的代码库，他们也会感到烦恼。
有没有人有经验或建议？
相关问题：
声明：这是从另一个关于Git的线程中转贴过来的，但我还是推荐Mercurial。它涉及企业上下文中的分布式版本控制系统，因此我希望跨越贴文可以接受。我稍微修改了一下，以更好地适应这个问题：
与普遍意见相反，我认为在企业环境中使用分布式版本控制系统是一个理想的选择，因为它可以实现非常灵活的工作流程。首先，我将谈论使用DVCS vs. CVCS的区别，然后介绍最佳实践，最后讨论关于Git。
企业环境下的DVCS vs. CVCS：
我不会在这里讨论一般的优缺点，而是关注您的具体情况。通常认为，在企业环境中使用DVCS需要比使用集中式系统更加有纪律的团队。这是因为集中式系统提供了一种简单的方法来“强制执行”您的工作流程，而使用分布式系统需要更多的沟通和纪律来坚持已经建立的惯例。虽然这可能看起来增加了额外的开销，但是我认为增加的沟通对于使其成为良好的过程是有益的。您的团队将需要就代码、变更以及项目状态进行沟通。
另一个纪律方面的维度是鼓励分支和实验。以下是Martin Fowlers最近在版本控制工具中发表的一句话，他为这种现象找到了一个非常简洁的描述。
DVCS鼓励快速分支进行试验。在Subversion中可以进行分支，但是它们对所有人都可见的事实会阻止人们开展试验性工作。同样，DVCS鼓励对工作进行检查点：将不完整的更改提交到本地存储库，这些更改甚至可能无法编译或通过测试。在Subversion的开发者分支上也可以这样做，但是这种分支在共享空间中使人们不太可能这样做。
（这张图片是从Joel Spolsky的hginit.com中偷来的。）
在这一点上还有一件事情需要说，即使DVCS提供了很好的合并功能，这绝不是使用持续集成的替代品。即使在那个时候，你也有很大的灵活性：对于主干存储库，团队存储库，Q&A存储库等都可以使用CI。
企业环境中的Mercurial：
我不想在这里引发git vs. hg的争论，你已经考虑切换到DVCS了，这是正确的方向。以下是选择使用Mercurial而不是git的几个原因：
简而言之，在企业中使用DVCS时，我认为选择引入最少摩擦的工具非常重要。为了使过渡成功，特别需要考虑开发人员之间（关于VCS）的不同技能。
最后我想指出一些资源。Joel Spolsky 最近写了一篇论文，驳斥了很多反对 DVCS 的观点。必须提到其他人在很久以前就发现了这些反对观点。另一个好的资源是 Eric Sink 的博客，在那里他写了一篇关于企业 DVCS 面临的障碍的文章。
首先，最近关于在大型项目中使用DVCS的讨论是相关的:
Mercurial的一个问题是它似乎是围绕着每个“项目”拥有单个仓库的想法设计的。
是的，虽然Subversion的规范是在一个单一的仓库中包含多个项目，但使用DVCS最好拥有更精细的仓库，每个组件一个。Subversion有svn:externals功能，在检出时聚合多个源树（这有其自身的后勤和技术问题）。Mercurial和Git都有类似的功能，称为子仓库。
子仓库的想法是您对于每个组件都有一个仓库，并且可发布的产品（由多个可重用组件组成）将简单地引用其依赖仓库。当您克隆产品仓库时，它会带上所需的组件。
我们是否应该拥有一个包含所有内容的巨大Mercurial存储库？如果不是，较小的存储库应该有多细粒度？我认为如果人们必须从许多不同的地方拉取和推送更新，他们会发现这非常烦人，但如果他们必须拉/推整个公司代码库，他们也会感到烦恼。