Question

我有一个名为MySharedLib的仓库，另一个名为MyProject的仓库。 MySharedLib通过强制拉动（如Jedi）包含在许多不同的回购中，而不是使用子版本。

如果您克隆MyProject，则会留下以下结构：

/MyProject
    MySharedLib
    OtherStuff
    Files...

MySharedLib不是subrepo。从MySharedLib中提取更改就像运行一样简单：

hg pull -f path/to/MySharedLib.

但是如果对/ MyProject / MySharedLib进行了更改，那么将这些更改仅推送到MySharedLib仓库的最直接/最标准的方法是什么？

MQ？ hg出口？ hg diff？ hg移植？我的理解是，几乎所有这些选项都有效（有些在一起，有些分开），但我想要一些方向。

然后如果开发者提交包含除MySharedLib之外的其他文件的提交会发生什么？显然这是要避免的，但我只是好奇。

Answer 1

以下是约束你可以推动的内容：

你只能推送整个变更集 - 如果你一起进行一些更改，那么在推送前端是全部或者没有，你提交后就无法分解变更集
如果不将所有祖先的变更集推送到

所以，一旦你提交了这样的线性历史：

[0]---[1]----[2]-----[3]

你可以在不推动两个和三个的情况下推动变更集零和一个，但如果你想推两个你也必须推零和一个。

如果变更集包含对/ MyProject / OtherStuff和/ MyProject / MySharedLib /的更改，则必须将它们组合在一起。

在你可以控制的地方提交之前，你唯一的灵活性就是：

变更集的内容
变更集的父母是什么（也必须用它推动）

因此，如果您的历史记录如下：

[0]---[1]

和hg status显示的内容如下：

M MyProject/OtherStuff/file1
M MyProject/OtherStuff/file2
M MyProject/MySharedLib/file3
M MyProject/MySharedLib/file4

然后你想创建一个只有你想要推送的MySharedLib更改的新变更集：

hg commit --include MyProject/MySharedLib

让你的历史看起来像：

[0]----[1]-----[2]

然后，在提交OtherStuff中的更改之前，您不希望推动hg update更改当前的parent版本，以便您的新变更集的父级为1两个：

hg update 1

现在你做的时候：

hg commit

你的新变更集三，只有非MySharedLib更改，父变为一，所以历史记录将如下所示：

[0]-----[1]--------[2]
          \
           --------[3]

由于两个和三个不是彼此的祖先，你可以推动任何一个而不推另一个。

那就是说，全方位是正确的：你的用法不仅仅是奇怪的，而是出错了。你应该看一下subrepo设置。它几乎肯定会比你或我刚才描述的更好地实现你的目标。

Answer 2

哇，多么奇怪的设置。如何防止MySharedLib的更改被推送到MyProject？除非你在拉动它们之后进行合并，否则MySharedLib中的文件是如何出现的？合并后，repos会加入，您需要先使用hg convert（如此question about splitting repositories中所述）将它们重新分开。

不要这样做。使用subrepos。这个问题就是他们要解决的问题。

如何将特定更改集推送到Mercurial中的共享库存储库？

2 个答案: