Mercurial 1.4.x中的subprepos功能是否可以用于生产环境？

Question

我想评估Mercurial是否适用于我的工作项目。但是我的大部分项目非常依赖于类似svn:externals的支持。我在StackOverflow上搜索并谷歌了Mercurial中相应的支持，但是我找到的只有在Mercurial 1.3中添加的subrepo功能，但此功能页面说：

subrepos是Mercurial 1.3的试验性功能。因此不要在关键任务存储库上使用！

我不想使用不稳定的东西。

有人能否介绍一下这个功能的真实状态以及完善/完成它的计划，以及何时会被称为“稳定”并准备好用于关键任务存储库？

- bialix

---

我已经更新了维基，以便更清楚地说明状态，希望这有所帮助。 - Martin Geisler

Answer 1

在 #mercurial IRC 频道中，有消息称子仓库将继续按照现有方式工作，并会得到更好的支持。例如，目前的 'hg status' 命令不支持子仓库 -- 它可以使用，但不会递归，但在未来将会支持。然而，当前的行为和文件格式 (.hgsub 和 .hgsubstate) 只会以向后兼容的方式进行更改。

因此，请放心使用，并期待它变得更好。

另外，从 mercurial 1.4.2 开始，子仓库现在可以是 subversion 仓库，因此您可以使用一个 mercurial 父仓库和一个 svn 子仓库。

- Ry4an Brase

---

那么这个功能没有明确的路线图吗？比如说，在 hg 1.6（或1.7）中它应该几乎完成，或者类似的情况？ - bialix

现在已经足够完整可以使用了。一些工作流程在未来会稍微简化，但现在已经完成了。 - Ry4an Brase

Answer 2

到目前为止，我在使用中的体验还不错。这个功能在以下两个方面非常有用：

1. 使用单个hg pull命令备份一组无关联的代码库。
2. 将项目与其依赖项的特定版本绑定在一起，以便使用单个hg clone获取可构建的源代码。这更接近于典型的svn:externals用法。

以下是我迄今为止看到的一些限制：

1. 在上述情况＃1中，您必须同时提交所有子代码库。这只会偶尔让人感到烦恼，因为Mercurial（像任何DVCS一样）鼓励频繁提交-因此大多数代码库不会处于不完整状态。
2. 只有最基本的Mercurial命令支持子代码库：clone、push/pull、update/commit，以及可能还有其他一些。
3. 扩展程序作者需要时间来针对具有子代码库的代码库测试其扩展程序。

当Mercurial团队将某个功能描述为“实验性”的时候，他们并不是指它会突然决定抹掉你的所有数据。他们只是意味着他们还没有编写处理所有边缘情况的代码，例如名称冲突（例如，一个开发人员添加了名为README的子仓库，而另一个开发人员添加了一个名为README的文本文件）。

- Erin Dees

---

我的使用情况是您第一个列表中的第二种。 - bialix