8

我想为我的工作项目评估 Mercurial。但是我的大多数项目都非常依赖于 svn:externals 的支持。我搜索了 StackOverflow 并在 Mercurial 中搜索了相应的支持。我发现的只是 Mercurial 1.3 中添加的 subrepo 功能，但该功能的页面说：

subrepos 是 Mercurial 1.3 的实验性功能。所以不要在关键任务存储库上这样做！

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

任何人都可以了解此功能的真实状态，抛光/完成它的计划以及何时将其称为“稳定”并为关键任务存储库做好准备？

4

2 回答 2

6

#mercurial IRC 频道中的一句话是，子存储库将继续像它们一样工作，并且支持将会增长。例如，目前“hg status”命令不支持 subrepo ——它可以工作，只是不递归，但将来会。但是，当前的行为、文件格式（.hgsub 和 .hgsubstate）只会以向后兼容的方式进行更改。

所以，现在就继续指望它，并期待它变得更好。

PS 从 mercurial 1.4.2 开始，subrepos 现在可以是 subversion repos，所以你可以使用一个 mercurial parent 和一个 svn child。

于 2010-02-06T21:54:07.353 回答
1

到目前为止，我在（轻度）使用它时对这个功能很幸运。它在两个地方派上用场：

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

以下是我到目前为止看到的一些限制：

  1. 在上面的情况 #1 中，您必须一次提交所有子存储库。这只是偶尔令人讨厌，因为 Mercurial（就像任何 DVCS 一样）鼓励频繁提交——所以大多数 repos 一开始就不会处于不完整的状态。
  2. 只有最基本的 Mercurial 命令是 subrepo 感知的：clone、push/ pull、update/ commit，也许还有其他几个。
  3. 扩展作者将需要时间来针对带有子存储库的存储库测试他们的扩展。

当 Mercurial 团队将该功能描述为“实验性”时，他们并不意味着它会突然决定删除您的所有数据。它们只是意味着他们没有针对所有边缘情况进行编码，例如名称冲突（例如，一个开发人员添加了一个名为 的子存储库README，而另一位开发人员添加了一个名为 的文本文件README）。

于 2010-02-06T21:35:08.217 回答