我已经将Mercurial用于我自己的个人项目一段时间了，我喜欢它。我的雇主正在考虑从CVS转换到SVN，但我想知道我是否应该推动Mercurial（或其他一些DVCS）。
Mercurial的一个问题是它似乎是围绕每个“项目”拥有一个存储库的想法而设计的。在此组织中，当前CVS存储库中有许多不同的可执行文件，DLL和其他组件，这些组件按层次结构组织。有许多通用的可重用组件，但也有一些客户特定的组件和客户特定的配置。当前的构建过程通常会从CVS存储库中获取一些子树。
如果我们从CVS迁移到Mercurial，那么组织存储库/存储库的最佳方法是什么？我们应该有一个包含所有内容的巨大Mercurial存储库吗？如果不是，那么较小的存储库应该有多细粒度？我认为如果他们必须从许多不同的地方提取和推送更新，人们会觉得非常烦人，但如果他们必须拉/推整个公司的代码库，他们也会觉得很烦人。
有人有这方面的经验或建议吗？
相关问题：
答案 0 :(得分：55)
答案 1 :(得分：44)
答案 2 :(得分：8)
首先，最近关于在大型项目中使用DVCS的一些讨论是相关的：
Distributed version control for HUGE projects - is it feasible?
Mercurial的一个问题是它似乎是围绕每个“项目”拥有一个存储库的想法而设计的。
是的，虽然Subversion的标准是拥有一个包含多个项目的单一存储库，但使用DVCS时，最好有更多粒度的存储库，每个组件一个。 Subversion具有svn:externals功能，可在结账时聚合多个源树（具有自己的后勤和技术问题）。 Mercurial和Git都有类似的功能，在hg中称为subrepos。
subrepos的想法是每个组件都有一个repo，可释放的产品（包含多个可重用的组件）将简单地引用其依赖的repos。当您克隆产品仓库时，它会带来所需的组件。
我们是否应该拥有一个包含所有内容的巨大Mercurial存储库？如果不是，那么较小的存储库应该有多细粒度？我认为如果他们必须从许多不同的地方提取和推送更新，人们会觉得非常烦人，但如果他们必须拉/推整个公司的代码库，他们也会觉得很烦人。
当然可以拥有一个整体存储库（如果需要，您甚至可以将其拆分为轨道）。这种方法的问题更可能归结为发布schedles，以及如何管理不同组件的不同版本。如果您有多个产品，他们自己的发布计划共享通用组件，那么您可能会采用更细粒度的方法，以促进配置管理。
有一点需要注意的是，subrepo支持是一个相对较新的功能，并不像其他功能那样完全成熟。具体来说，并非所有的hg命令都知道subrepos，尽管最重要的是。
我建议您执行测试转换，并尝试使用subrepo支持，组织产品和相关组件等。我正在做同样的事情，这似乎是要走的路。