我正在尝试为远程团队创建一个包。他们有一份来自修订版892的仓库副本，我们目前正在修订版1119.
首先我尝试了补丁，但是在尝试应用它们时（通常在合并提交时）创建了大量的文件... ...我们的存储库大小为17GB，所以我正在尝试创建一个delta补丁，因此认为hg捆绑是完美的。
我通过以下方式生成了一个包：
>hg bundle --rev 1119 --base 892 depot-892-to-1119.bundle
这创建了一个350MB的捆绑文件，这是可以接受的并且感觉正确。
但是当我们将它应用到仅转到修订版892的目标软件仓库时，它就会开启：
E:\dest-depot>hg unbundle -u depot-892-to-1119.bundle
adding changesets
transaction abort!
rollback completed
abort: 00changelog.i@e5cc33458251: unknown parent!
到目前为止，这与我在搜索时看到的其他几个问题类似，但我会更进一步。
我在源（更大的仓库）中查找了e5cc33458251，它显示为修订版930，显然是在转892之后，但指定这是失败的原因。当然，目的地仓库没有修订版。这就是为什么我首先创建了这个包......所以我不确定为什么这个会给我带来麻烦。
现在我们在软件仓库中有许多分支机构，而rev 892则在“Patch 2.7”分支上提示，而不是默认分支。我不知道这是否会引起问题。最终，补丁分支在rev 999中合并为默认值。
930实际上是对代码的一个非常小而微不足道的变化，也是在“补丁2.7”分支中。在修订图中实际上有2个Patch 2.7行，它们在932中合并在一起。但同样，没什么奇怪的。
我在这里没有看到问题。关于我应该产生什么样的捆绑的任何想法？或者，如果我要走另一条路？
答案 0 :(得分：2)
听起来你这样做基本上是正确的，所以让我们检查几个可能的问题：
您是否知道修订号不能在克隆中移植？ “他们的”892完全可能与你的不同。因此，您应该通过nodeid找出他们的最新修订版本，并将其用作基础参数。
我认为远程使用hg的内部协议来实际传输数据可能不太可行，但是如果你可以让他们在hg serve暂停一段时间你就可以做到：
hg bundle ../depot-to-them.bundle http://THEIR_IP:8000
然后，您将获得完全正确的捆绑包，以获得他们所需的一切，而无需让他们向您发送他们的节点名称。
除了可能值得一提的唯一其他信息之外，通过使用--rev X --base Y你会说“我想发送他们没有的所有X的祖先，如果他们只有Y和它的祖先“，所以如果有一个尚未合并到X的分支你将不会发送它，即使本地修订号在X和Y之间。但这不会阻止捆绑被应用，所以这更像是一种善于理解而不是可能导致你的麻烦的原因。