如何基于脚本拒绝对 Mercurial 服务器的推送，而不冒在此期间拉取失败的风险？
我想编写一个脚本，用于检查推送到 Mercurial 服务器时传入的变更集，并在变更集不符合特定标准时拒绝推送。看来我的选项是 prechangegroup、pre-changegroup 和 pretxnchangegroup 挂钩。不幸的是，prechangegroup 和 pre-changegroup 挂钩似乎无法访问传入的变更集，因此我需要 pretxnchangegroup。但根据 http 的文档://hgbook.red-bean.com/read/handling-repository-events-with-hooks.html#sec:hook:pretxnchangegroup，这可能会导致在挂钩启用时使用存储库的人员状态不一致执行：
“当此钩子运行时，如果其他 Mercurial 进程访问此存储库，它们将能够看到几乎添加的变更集，就好像它们是永久的一样。如果您不采取措施避免它们，则可能会导致竞争条件”
如果有人在我的脚本拒绝变更集的过程中进行拉取，那么我真的不会对随机奇怪的情况感到疯狂。我可以使用另一个钩子吗？如果没有，我需要采取哪些“避免它们的步骤”？有没有办法可以在挂钩期间锁定存储库？
I'd like to write a script that examines the incoming changesets on a push to a mercurial server and rejects the push if the changesets do not conform to a particular standard. It seems like my options are the prechangegroup, pre-changegroup, and pretxnchangegroup hooks. Unfortunately, the prechangegroup and pre-changegroup hooks do not appear to have access to the incoming changesets, so I would need pretxnchangegroup. But according to the documentation at http://hgbook.red-bean.com/read/handling-repository-events-with-hooks.html#sec:hook:pretxnchangegroup, this can lead to inconsistent state for people using the repository while the hook is executing:
"While this hook is running, if other Mercurial processes access this repository, they will be able to see the almost-added changesets as if they are permanent. This may lead to race conditions if you do not take steps to avoid them."
I'm really not crazy about random weirdness happening if someone does a pull while my script is in the process of rejecting a changeset. Is there another hook that I can use? If not, what are the "steps to avoid them" that I need to take? Is there a way I can lock the repository during my hook?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您展开引用段落的评论，Meister Geisler 证实了一些用户的观察结果，即该问题自 hg 以来已得到解决1.2，这样尚未永久传入的变更集是不可见的，因此不会被拉取。
If you expand the comments for the quoted paragraph, Meister Geisler confirmed some users' observation that the issue was resolved since hg 1.2, such that the not-yet-permanent incoming changesets are not visible, thus will not be pulled.