Question

可以：

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？这是很多步骤！

Answer 1

在您的情况下，第四个选项可能会更好： Mercurial Queues 保存在本地Mercurial存储库中。

使用MQ，您可以：

在本地克隆主存储库。
处理您的代码并将更改隔离在补丁中。
当上游的新更新可用时，请删除批次，应用更新，然后在新更新之上重新应用修补程序。
一旦您对自己的工作感到满意，请将其折叠到本地存储库并将其推向上游。

您不必将补丁保留在本地存储库中，但这是一个值得考虑的好方法。

Chapter 12

Mercurial: The Definitive guide以相当详细的方式解释了该过程。

Answer 2

我不知道你对空间考虑的理解是正确的。克隆本地存储库时，Mercurial将使用.hg目录的硬链接，即实际存储库，它不占用额外的空间。工作目录占用空间（虽然希望不是500GB！）但.hg目录看起来就像它用来检查。

如果您执行clone -U，则创建一个没有工作目录的克隆，它几乎不占用任何额外空间并且几乎立即创建。

我始终将clone -U中央仓库保持在未修改状态，然后根据需要创建克隆。我直接从这些克隆推回到远程存储库。

Answer 3

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

什么是最好的Mercurial克隆/存储库策略？

3 个答案: