我们有一个很大的Hg仓库，托管在一个偏远的位置。从此主仓库执行hg clone大约需要一个小时。我们通常采取的措施是hg serve同事的本地回购hg clone http://colleague-machine，然后将default中的de .hg/hgrc路径更改为主人的地址回购。
这一切都很好，但是这个解决方法有一个缺点：因为我们克隆了开发人员的回购，一些草稿提交可以与公共提交一起克隆。而且，这些提交在克隆的回购中变得公开，使得它们与其他提交无法区分。
我找到的一种可能性是make the developer's repo non publishing，以便保留提交的阶段并在以后删除它们。另一种可能性是创建一个仅包含公共提交的包，而不是直接克隆。
这些方法解释和记录起来比较复杂。是否有hg clone只能克隆公共提交的选项？我尝试使用hg clone -r "public()"，但克隆不采用revset，只是一个常规的提交标识符。或者，hg serve是否只有一个选项才能提供公共提交？
答案 0 :(得分：1)
执行此操作的一种方法是使用hg clone -r <rev>公开<rev>。这将确保您不会获得任何草稿提交，但您将错过任何不是<rev>的祖先的分支。
我不认为这是克隆公共更改的通用方法。虽然可以通过服务器端扩展或进程内挂钩来实现。
答案 1 :(得分：1)
在问题处抛出磁盘空间：只保留定期更新的本地镜像克隆。
克隆＆＃34;真正的大师＆＃34;很慢，因为它远远超过慢速链接。但是更新镜像很快，因为虽然真正的主机远远超过慢速链接，但很少需要数据遍历它;并且克隆镜像很快，并且在上次镜像更新时获取真正主服务器的状态。
正如您所提到的，您可以只替换default路径（如果需要，可以运行后续的hg pull来获取尚未镜像的任何内容）。如果你从遥远的慢速真正的主人那里克隆出来，那么你的新克隆就像以前一样，除非它的速度很快。
Git内置了这种克隆，正如所谓的引用克隆。您将git clone进程指向两个存储库：真正的源，＆＃34;关闭和快速＆＃34;参考。它从真实源获取哈希ID，但随后使用快速参考的存储来获取其数据。然后，您可以选择继续依赖参考（默认）或＆＃34; disociate＆＃34;从引用中，以便您的克隆是独立的。它需要这种分离操作，因为它可以做一个有点危险的基于路径名称的链接＆＃34; （并不是真正的硬链接意义上的链接;更多是符合链接的符合链接的内容），默认情况下这样做。
我不认为Mercurial有任何与开箱即用相同的东西＆＃34;。我认为，作为一个扩展，编写它应该相对容易，但是，如果你想做那种事情。您根本不需要--dissociate，只要硬链接不可行，它就是默认值。
答案 2 :(得分：0)
我最终使用了hg serve选项和hg strip的组合。
在现有存储库中：
hg serve --config phases.publish=False --port 0 --prefix repo-name
在目标计算机上：
hg clone <address printed by `hg serve`>
cd repo-name
hg strip -r "draft()"
phases.publish=False配置使repo不发布，从而保留了克隆的提交阶段。既然阶段保留在目标机器上，那么在克隆之后很容易将它们剥离。