mercurial - 在大型组织中使用 Mercurial

Question

一段时间以来，我一直在将 Mercurial 用于我自己的个人项目，我喜欢它。我的雇主正在考虑从 CVS 切换到 SVN，但我想知道是否应该插入 Mercurial(或其他一些 DVCS)。

Mercurial 的一个缺点是它似乎是围绕每个“项目”拥有一个存储库的想法设计的。在这个组织中，当前 CVS 存储库中有几十个不同的可执行文件、DLL 和其他组件，按层次组织。有很多通用的可重用组件，但也有一些客户特定的组件和客户特定的配置。当前的构建过程通常会从 CVS 存储库中获取一些子树集。

如果我们从 CVS 迁移到 Mercurial，组织存储库的最佳方式是什么？我们是否应该拥有一个包含所有内容的巨大 Mercurial 存储库？如果不是，那么较小的存储库应该有多细？我认为如果人们不得不从很多不同的地方拉和推更新，他们会觉得很烦人，但如果他们必须拉/推整个公司代码库，他们也会觉得很烦人。

有人有这方面的经验，或者建议吗？

相关问题:

Git-Based Source Control in the Enterprise: Suggested Tools and Practices?

Distributed version control for HUGE projects - is it feasible?

Answer 1

首先，最近关于在大型项目中使用 DVCS 的一些讨论是相关的:

Distributed version control for HUGE projects - is it feasible?

One wrinkle with Mercurial is that it seems to be designed around the idea of having a single repository per "project".

是的，虽然 Subversion 的标准是拥有一个包含多个项目的单一存储库，但对于 DVCS，最好拥有更细粒度的存储库，每个组件一个。 Subversion 有 svn:externals在结帐时聚合多个源树的功能(这有其自身的后勤和技术问题)。 Mercurial 和 Git 都有一个相似的特性，称为 subrepos。在 Mercurial 。

subrepos 的想法是每个组件都有一个 repo，而可发布的产品(包含多个可重用组件)将简单地引用其依赖的 repos。当您克隆产品存储库时，它会带来它需要的组件。

Should we have one huge Mercurial repository containing everything? If not, how fine-grained should the smaller repositories be? I think people will find it very annoying if they have to pull and push updates from a lot of different places, but they will also find it annoying if they have to pull/push the entire company codebase.

当然可以有一个单一的存储库(如果需要，您甚至可以将其拆分为轨道)。这种方法的问题更可能归结为发布时间表，以及您如何管理不同组件的不同版本。如果您有多个产品，它们有自己的发布时间表共享公共(public)组件，那么您可能最好采用更精细的方法，以促进配置管理。

需要注意的是，subrepo 支持是一个相对较新的功能，并不像其他功能那样成熟。具体来说，并非所有 hg 命令都知道 subrepos，尽管最重要的命令知道。

我建议您进行测试转换，并尝试 subrepo 支持，组织产品和依赖组件等。我正在做同样的事情，这似乎是要走的路。