version-control - 额外的 "push -f"/仅备份 Mercurial 存储库是否有效？

Question

我们已经建立了自己的 Mercurial 工作流程，这对我们来说非常有用。然而我想知道一件事:是否有可能创建一些“垃圾”存储库，基本上每个用户都可以在其中“push -f”他们的变更集，而除了“push -f”之外我们永远不会做任何事情？

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

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

我刚刚对三个用户进行了测试，执行“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)来记录变更集的推送时间和推送位置，那么这应该可以帮助您在恢复时找到所需的变更集。