额外的“push -f”/仅备份 Mercurial 存储库是否有效？
我们已经建立了自己的 Mercurial 工作流程，这对我们来说非常有用。然而我想知道一件事：是否有可能创建一些“垃圾”存储库，基本上每个用户都可以在其中“push -f”他们的变更集，并且除了“push -f”之外我们永远不会做任何事情？
也就是说：该存储库的目标不是是集成/合并/拉取。实际上，它不会成为我们工作流程的一部分。它实际上只是一个“备份所有变更集的地方”。
我们从中检索变更集的唯一时刻是，如果用户遇到硬盘崩溃或被盗，并且他将变更集“推送 -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
一旦用户开始从其他存储库中提取数据、合并他们的工作等，这会继续工作吗？
换句话说，这将是一个存储库，其中解决合并问题不会成为问题，“push -f”和创建新头将非常受欢迎，并且工作目录的父级将始终停留在“变更集 0”。它的唯一目标是充当“变更集备份”文件夹（例如，备份尚未集成到我们实际工作流程中的变更集）。
这会起作用吗？这有什么意义吗？
（请注意，如果这没有任何意义，也不会使问题变得不那么有趣，其他人可能想要这样做，然后可能想找出为什么它没有意义）
We've set up our own Mercurial workflow which works great for us. However I'm wondering about something: is it possible to create some "junk" repository that would basically be a place where every user could always "push -f" their changesets and where we'd never do anything besides "push -f"?
That is: the goal of that repository would not be to integrate/merge/pull. Actually it would not be part of our workflow. It would really just be a "place to backup all the changesets".
The only moment we'd retrieve a changeset from it is if a user got a hard disk crash or a theft and had changesets that he "pushed -f" to this hypotethic "changeset backup" repo but not to the repository(ies) part of our real workflow (there'd be plenty of reason why this would happen: one of them being that keeping an always accessible "unverified" junk repository always available would be very easy).
I just did a test with three users doing "push -f" and now it looks like the following (note that the parent of the working directory stays at the very bottom, at changeset 0, and would forever stays there):
$ 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
Would this keep working once users starts pulling from other repositories, merging their work, etc.?
In other words it would be a repositories where resolving merging issues wouldn't be a concern and where "push -f" and creating new heads would be very welcome and where the working directory's parent would always stays at "changeset 0". It's only goal would be to serve as "changesets backup" folder (for example to backup changesets that haven't been integrated yet in our real workflow).
Would this work and does this make any sense?
(note that should this not make any sense wouldn't make the question less interesting, other people may want to do exactly this and then may want to find why it wouldn't make sense)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
是的，它会工作得很好。你的“垃圾”存储库最终会留下大量的头。
您可以使用 hg pull -r 从垃圾存储库中检索特定的变更集（及其所有祖先），因此您不必担心必须将所有这些内容合并在一起。
现在，跟踪哪个变更集是哪个变更集，以及您想要拉取哪个变更集以恢复丢失的内容是一个更难的问题。你可以看那棵树，但这棵树会变得复杂、茂密，有很多头。当然，这仍然是可以做到的，只是不一定是微不足道的。
如果您使用一些钩子来记录变更集的推送时间和推送位置，那么这应该可以帮助您在恢复时找到所需的变更集。
Yes, it would work just fine. Your 'junk' repository would just end up with a ton of heads.
You can use
hg pull -rto retrieve a particular changeset (and all of its ancestors) from the junk repository, so you won't have to worry about ever having to merge together all that cruft.Now, keeping track of which changeset is which, and which one you want to pull in order to restore something you've lost is a harder question. You can look at the tree, but that tree is going to get complicated and bushy with lots of heads. It can still be done of course, it's just not necessarily trivial.
If you use some of the hooks to keep a log of when changesets were pushed and where they were pushed from, that should help you find the one you want when it comes time to recover things.
任何备份方法的有用性只能通过恢复能力来衡量。在这种情况下，我认为您没有有效的恢复路线。
如果这不是您想要的答案，那么我很抱歉，因为您已经有了一个工作流程，但处理备份的另一种方法是让每个开发人员克隆（可能是备份的）服务器上的“主”存储库，然后从那个克隆中拉出来。然后，他们可以根据需要随时推送回服务器上的“他们的”克隆，并且仅根据需要将变更集提升到主存储库。
这会将变更集获取到某个中央服务器上，并使恢复更加简单，因为每个开发人员的变更集都是隔离的。
我确信您考虑过的另一个选择是为本地开发人员的 PC 提供单独的备份过程。也许是在后台自动化的东西，比如Carbonite？
希望这有帮助。
The usefulness of any backup method can only be measured by the ability to restore. In this case, I don't think you'd have an efficient restore route.
Apologies if this isn't the answer you're after since you've already a workflow in place, but another way to handle backups is by having each developer clone the 'main' repository on the (presumably backed-up) server and then pulling from that clone. They then push back to 'their' clone on the server as often as they want and only promote the changesets to the main repository as required.
This will get the changesets on a central server somewhere and make the restore more straightforward as each developer's changesets are isolated.
The other option I'm sure you've considered is a separate backup process for local developer's PCs. Perhaps something automated and in the background like Carbonite?
Hope this helps.