可以：
1）根据需要从远程仓库克隆（每个新的可能需要20分钟和500MB）
2）从远程仓库克隆2个本地的，都是500MB，总共1GB，所以总是有2个本地仓库可供使用
3）从远程仓库克隆1本地一个，称为“master”，然后不要触摸此主服务器，但根据需要从该主服务器克隆其他本地服务器
我开始使用（1），但是当有快速错误修复时，我需要做一个克隆，它是20分钟，所以方法（2）更好，因为有2个独立的本地回购所有时间。
但有时候回购会变得“怪异”，因为合并会造成损害，当它被修复到远程仓库时，hg outgoing中出现的任何本地仓库合并将在我们再次推动时造成损害，所以我们只是删除那个本地仓库并再次从远程克隆开始“新鲜”，再次花20分钟。 （实际上，我们可以首先使用本地回购2，将本地回购1重命名为repo_old，然后在睡觉前或回家之前再次进行克隆）
（3）是最好的选择吗？因为在Mac上，主机需要500MB和20分钟，但是其他本地克隆速度超快且需要少于500MB，因为它在Mac上使用硬链接（如何在没有硬链接内容的情况下找出多少磁盘空间？ ）。如果使用（3），我们如何做提交和推送？假设我们从远程repo克隆到本地作为“master”，然后克隆本地的“clone01”，“clone02”，03等，然后我们在clone01内部工作，然后当需要紧急修复时，我们去要掌握，执行hg pull和hg update，然后转到clone02并执行hg pull和hg update，并在clone02上修复它，测试它，{{1 }，hg commit给主人，然后去掌握，并在那里做hg push？然后当clone01的项目完成后，再次进入master，pull，update，转到clone01，pull，update，merge，test，commit，push，go to master，push to remote repo？这是很多步骤！
答案 0 :(得分：5)
在您的情况下，第四个选项可能会更好： Mercurial Queues 保存在本地Mercurial存储库中。
使用MQ，您可以：
您不必将补丁保留在本地存储库中，但这是一个值得考虑的好方法。
来自Chapter 12的Mercurial: The Definitive guide以相当详细的方式解释了该过程。
答案 1 :(得分：2)
我不知道你对空间考虑的理解是正确的。克隆本地存储库时，Mercurial将使用.hg目录的硬链接，即实际存储库，它不占用额外的空间。工作目录占用空间（虽然希望不是500GB！）但.hg目录看起来就像它用来检查。
如果您执行clone -U，则创建一个没有工作目录的克隆，它几乎不占用任何额外空间并且几乎立即创建。
我始终将clone -U中央仓库保持在未修改状态，然后根据需要创建克隆。我直接从这些克隆推回到远程存储库。
答案 2 :(得分：0)
Mercurial Queues 看起来非常强大，但我从来没有给自己时间 阅读所有文档，只是为了能够把我目前的工作放在一边 做一个小虫子。
我使用attic扩展名。
就像这样：
...working happily, but then there is a quick bug fix...
$hg shelve work
...quickly fix the bug...
$hg ci
$hg unshelve
...continue with work
有时我会有一个想法，但没有时间真正玩它。为了防止我忘记它。
...working happily, idea drops in...
$hg shelve work
...start a unittest for the idea or some other unfinished piece of code, enough to sketch the idea
$hg shelve idea
$hg unshelve work
...continue with work
$hg ls
idea
*C work