我们已经建立了自己的Mercurial工作流程，这对我们非常有用。但是我想知道一些事情：是否有可能创建一些“垃圾”存储库，基本上每个用户都可以“推送”他们的变更集，以及除了“push -f”之外我们什么都不做？
那就是：该存储库的目标不是集成/合并/拉取。实际上它会不成为我们工作流程的一部分。它实际上只是一个“备份所有变更集的地方”。
我们从中检索变更集的唯一时刻是，如果用户遇到硬盘崩溃或被盗，并且有变更集，他将“-f”推送到这个次要的“变更集备份”仓库而不是存储库（ ies）我们真正的工作流程的一部分（有很多理由为什么会发生这种情况：其中一个原因是保持一个始终可访问的“未经验证的”垃圾存储库始终可用非常容易。）
我刚刚对三个用户进行了“push -f”测试，现在它看起来如下（注意工作目录的父级保持在最底层，在变更集0，并且永远< / strong>留在那里）：
$ 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
一旦用户开始从其他存储库中提取，合并他们的工作等，这会继续工作吗？
换句话说，它将是一个存储库，其中解决合并问题不会成为一个问题，并且“push -f”和创建新的头部将非常受欢迎，并且工作目录的父级将总是保持在“changeset 0”。它的唯一目标是作为“更改集备份”文件夹（例如，备份尚未在我们的实际工作流程中集成的变更集）。
这会起作用并且这有意义吗？
（请注意，如果这没有任何意义，不会使问题变得不那么有趣，其他人可能想要做到这一点，然后可能想找到为什么它没有意义）
答案 0 :(得分：2)
是的，它会正常工作。你的“垃圾”存储库最终会有大量头脑。
您可以使用hg pull -r从垃圾存储库中检索特定的变更集（及其所有祖先），这样您就不必担心必须将所有这些变更合并在一起。
现在，跟踪哪个变更集是哪个变量集，以及为了恢复丢失的东西而想要拉出哪个变更集是一个更难的问题。你可以看一下这棵树，但那棵树会变得复杂而浓密，有很多头。它当然可以完成，它不一定是微不足道的。
如果你使用一些钩子来记录推送更改集的时间以及推送它们的位置，那么这应该可以帮助你在恢复时找到你想要的那个。
答案 1 :(得分：1)
任何备份方法的有用性只能通过恢复能力来衡量。在这种情况下，我认为你没有一个有效的恢复路线。
如果这不是你已经完成工作流程的答案，那么道歉，但处理备份的另一种方法是让每个开发人员克隆“主要”存储库（可能是备份的）服务器，然后从该克隆拉。然后，他们会根据需要随时返回服务器上的“他们的”克隆，并根据需要仅将更改集提升到主存储库。
这将在某个中央服务器上获取更改集，并使每个开发人员的更改集被隔离，从而使恢复更加简单。
我确定您考虑的另一个选项是本地开发人员PC的单独备份过程。也许是自动化的，在后台像Carbonite？
希望这有帮助。