version-control - 额外的 "push -f"/backup-only Mercurial repo 会起作用吗？

Question

我们建立了自己的 Mercurial 工作流程，非常适合我们。但是我想知道一些事情:是否有可能创建一些“垃圾”存储库，基本上每个用户都可以始终“push -f”他们的变更集，并且除了“push -f”之外我们永远不会做任何事情?

即:该存储库的目标是 不是 是整合/merge/拉动。实际上它会不是 成为我们工作流程的一部分。它实际上只是一个“备份所有变更集的地方”。

我们从中检索变更集的唯一时刻是，如果用户遇到硬盘崩溃或被盗，并且有他“推 -f”到这个假设的“变更集备份”存储库而不是存储库部分的变更集我们真正的工作流程(发生这种情况的原因有很多:其中之一是保持始终可用的“未验证”垃圾存储库始终可用将非常容易)。

我刚刚对三个执行“push -f”的用户进行了测试，现在它看起来如下所示(请注意，工作目录的父级位于最底部，位于变更集 0 处，并且 将永远存在 那里):

$ hg glo | grep -v user: | grep -v date
o  changeset:   3:4337a665659f
|  tag:         tip
|  parent:      0:ab3e3171d569
|  summary:     1st change by user B
|
| o  changeset:   2:2349e3eed60d
|/   parent:      0:ab3e3171d569
|    summary:     1st change by user C
|
| o  changeset:   1:10405f5e0994
|/   summary:     1st change by user A
|
@  changeset:   0:ab3e3171d569
   summary:     Init

一旦用户开始从其他存储库中提取、 merge 他们的工作等，这是否会继续工作？

换句话说，这将是一个不需要解决 merge 问题的存储库，并且非常欢迎“push -f”和创建新头，并且工作目录的父级将在其中 总是 停留在“变更集 0”。它的唯一目标是充当“变更集备份”文件夹(例如，备份尚未集成到我们实际工作流程中的变更集)。

这会起作用吗？这有意义吗？

(请注意，如果这没有任何意义不会使问题变得不那么有趣，其他人可能想要完全这样做，然后可能想找出为什么它没有意义)

Answer 1

是的，它会工作得很好。您的“垃圾”存储库最终会得到大量的人头。

您可以使用 hg pull -r从垃圾存储库中检索特定的变更集(及其所有祖先)，因此您不必担心必须将所有这些杂物 merge 在一起。

现在，跟踪哪个变更集是哪个变更集，以及您想要拉出哪个变更集以恢复您丢失的东西是一个更难的问题。你可以看看这棵树，但那棵树会变得复杂而浓密，有很多头。当然，它仍然可以完成，只是不一定是微不足道的。

如果您使用一些钩子(Hook)来记录更改集何时被推送以及它们被推送到哪里，那应该可以帮助您在需要恢复时找到您想要的那个。