在osx上设置mercurial/回转窑子回购

我一直在尝试按照答案中的说明，使用窑炉

我希望能够安排如下事项：

• /somepath/thirdparty

  映射到窑炉存储库“thirdparty”，并包含各种代码

• /somepath/common

  映射到窑库“common”，并包含我编写的共享代码

及

• /somepath/project1

  映射到窑库“project1”

• /somepath/project1/thirdparty

  映射到上面第三方的分支

• /somepath/project1/common

  映射到上面的common分支

及

• /somepath/project2

  映射到窑库“project1”

• /somepath/project2/thirdparty

  映射到上面第三方的另一个分支

• /somepath/project2/common

  映射到上述common的另一个分支

我发现，当我按照指示创建

.hgsub

文件并将其添加/推送到回转窑时，我无法再在回转窑web文件查看器中查看回转窑文件-它显示了一条关于回转窑“过热”的模糊消息：-），此外，它确实在正确的位置自动创建了子文件夹，它们没有填充文件（可能是因为拉操作失败）

以前有人用过这种方法吗

由于我打算使用通用代码开发一些应用程序（并可能最终以开源形式发布该库），我希望在离散的存储库中对其进行管理。然而，由于有些项目是面向最终客户的，我需要能够为他们提供一个包含上述内容的单一存储库。

。这意味着您不能同时使用以下两个URL：

http://server/kiln/somepath/project1
http://server/kiln/somepath/project1/thirdparty

因此，您应该设置回转窑，以便服务器上有四个存储库：

http://server/kiln/somepath/project1
http://server/kiln/somepath/project2
http://server/kiln/somepath/thirdparty
http://server/kiln/somepath/common

这很简单-只有四个普通的存储库。然后克隆“project”并使用以下内容创建

.hgsub

文件：

thirdparty = http://server/kiln/somepath/thirdparty
common = http://server/kiln/somepath/common

当您将其推回到回转窑时，它将注意到并显示子存储库的链接。但是，子存储库最终不会嵌套在服务器上。因此，服务器上不会有任何

project1/thirdparty

路径

你是否会想要这样还很不清楚。当您有多个项目进行协作并使用一些公共代码库时，您希望“project1”和“project2”能够获得彼此对该公共代码库的更改。因此，这两个项目中的

通用
子回购协议从
推送和拉送非常有用http://server/kiln/somepath/common

在Mercurial中，我们建议您在
.hgsub
文件中使用形式为
common=common
的路径。这意味着服务器必须支持嵌套存储库。当回转窑不支持嵌套回购时，可以使用完整路径

最初设置子存储库时，请记住需要手动更新它们。因此，使用上述URL，您可以通过运行以下命令来设置“project1”：

$ hg clone http://server/kiln/somepath/project1
$ echo "common =     http://server/kiln/somepath/common" > .hgsub
$ echo "thirdparty = http://server/kiln/somepath/thirdparty" > .hgsub
$ hg commit -m "Created subrepos"

这将创建初始的空子存储库。它们是空的，因为您没有告诉Mercurial您需要在它们中使用哪个变更集。这可在
.hgsubstate
中找到：

0000000000000000000000000000000000000000 common
0000000000000000000000000000000000000000 thirdparty

要填充您所做的子存储库

$ cd common
$ hg pull --update
$ cd ../thirdparty
$ hg pull --update
$ cd ..
$ hg commit -m "Updated subrepos"

这将使用两个子repo的当前tip变更集ID更新
.hgsubstate
中的
000…
行。“project1”的未来克隆将注意到
.hgsubstate
文件，并确保将subrepos更新为此处提到的版本。
@Martin Geisler-感谢您的编辑，现在阅读起来更容易了！没问题，我很乐意整理一下！：）嗯，这似乎就是我设置它的方式，但它失败了（我在服务器上没有嵌套的repo，只是在本地）。我将仔细观察，看看我的方法与你的答案有什么不同，以及是什么导致了这个错误。谢谢。据我所知，所有设置都是一样的，只是使用了https://而不是http://（主文件夹中的my[auth]部分my.hgrc文件具有相应的登录凭据）。我的实际路径有我不想在这里发布的全名，但除此之外，它在语义上是相同的。好吧，奇怪。当您
hg clone
项目时，Mercurial只需
hg clone
子回购即可。因此，请尝试手动克隆
server/kill/common
。若这不起作用，那个么窑中的回购协议就有问题了。我想你知道这一点，但子回购并不特别——它只是服务器上的普通回购。其他repo可以在
.hgsub
文件中引用它，但子repo不“知道”这一点。更多信息：当我在添加了.hgsub文件后将repo推回回转窑时，我发现它创建了一个具有适当名称的空文件夹，嵌套在项目文件夹中。然后我试图撤回回购计划，希望它也能拖入文件。在那一点上，我去了当时的窑炉网站，发现了有趣的“过热”信息。自从读了你上次的评论后，我尝试了“hg clone https://（myrepos\u url\u on\u kille）”，看看对整个事情进行新的克隆是否会有什么不同。结果：没有子文件夹，即.hgsub的推送未生效。顺便说一句：上述新克隆位于新文件夹中。