验证 Mercurial 签到
有没有办法在 Mercurial 中验证/验证签入？我想在我们的组织（60 多名开发人员）中推出 HG，并且我想要一种方法来确保每个人的签入都来自正确的用户，并且都采用正确的格式。
在试验期间，我们发现一些用户使用完全不同的用户名（复制其他人的 .hgrc 文件）进行签入，而其他用户则使用不同的客户端使用其姓名的多个不同版本（名字、全名、电子邮件地址等）进行签入。
我们可以添加一个钩子来强制用户名的格式，但它仍然不能保证它是正确的用户。 Mercurial 有什么办法可以管理这个问题，还是我只是陷入了 CVS/SVN 的思维方式？
谢谢， 戴夫.
Is there any way to verify/authenticate checkins in Mercurial? I'd like to roll out HG across our organisation (60+ developers) and I'd like a way to ensure everyone's checkins are from the correct user and that they are all in the correct format.
During trials we found that some users checked in under completely different usernames (copied someone else's .hgrc file) and others checked in under a number of different versions of their name (first name, full name, email address, etc) using different clients.
We could add a hook to enforce the format of the username but it still doesn't guarantee that it's the correct user. Does Mercurial have anything to manage this or am I just stuck in a CVS/SVN way of thinking?
Thanks,
Dave.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
大多数情况下，您采用的是 CVS/SVN 思维方式——如果您的员工不诚实，无论如何您都会被搞砸。 :) 然而，其他人已经通过多种技术处理了这个问题：
changegroup挂钩以确保进入受保护存储库的 cset 已由其作者签名，$REMOTE_USER变量（对于 http）进行比较，或者到$USER（对于 ssh）并要求它与推送用户匹配。这些都不能阻止错误提交，但您可以阻止错误提交进入受到如此保护的存储库。
不过，在实践中，这并不是每个人（包括我）想象的问题。人们最终会得到来自不同机器的同名的许多变体，但是任何通过用户名（流失等）运行的命令都会采用别名映射来帮助您在重要的情况下对它们进行分组。
Mostly you're in a CVS/SVN way of thinking -- if your employees are dishonest you're screwed anyway. :) However, there are a few ways that other folks have handled this using a variety of techniques:
changegrouphook to make sure that an csets entering a protected repo were signed by their author$REMOTE_USERvariable (for http) or to$USER(for ssh) and require that it match the push-ing user.None of those prevent a false commit, but you can stop a false commit from entering a thusly guarded repo.
Again though, in practice, it's just not the problem that everyone (including me) imagines it will be. One does end up with many variants of the same name from different machines, but any command that works by usernames (churn, etc.) will take an alias map to help you group them if it matters.
首先，您无法在提交时验证这一点，因为只有在将变更集推送到中央存储库后您才能访问变更集。
因此，您可以验证推送 cset 的人也是提交者（通过匹配 http 或 ssh 身份验证）。这有点限制，因为当人们推送其他开发人员的变更集时它可能很有用。
您可以使用 pgp 扩展（来自 hgext）在提交后显式签署变更集，但如果您想对每个变更集执行此操作，则有点麻烦。
commitsigs 是另一个扩展，它采用不同的签名策略。它将签名直接嵌入到变更集中，从而避免了额外变更集的混乱。这会给每个变更集增加大约 2 KB 的开销。
Mozilla 使用推送日志来跟踪谁推送了什么。这使您可以查看服务器上的提交历史记录（但仅在服务器上），以了解谁推送了哪组变更集，从而为您提供比通常获得的更好的书面记录。如果您在电子邮件中包含进行推送的人员，这也可以通过变更组通知来提供（这是 Python 在转换完成后将执行的操作）。
那么这些就是技术解决方案。另一方面，请多考虑一下：您已经授予一组人对您的中央存储库的推送访问权限。如果他们愿意，他们已经可以对你的树进行破坏了。如果您相信他们会将内容推送到您的中央树中，那么您是否也不能相信他们有最好的意图将自己的名字放在他们的变更集中？
First off, you cannot verify this at commit time, because you only have access to the changeset once it gets pushed to one of your central repositories.
So you could verify that whoever is pushing the cset is also the committer (by matching http or ssh authentication). This is somewhat limiting because it can be useful when people push other developer's changesets.
You could use the pgp extension (from hgext) to explicitly sign changesets after committing, but it's kind of a drag if you want to do it for every changeset.
commitsigs is another extension, which takes a different tack to signing. It embeds the signature directly in the changeset, thereby avoiding the clutter of an extra changeset. This adds an overhead of about 2 KB to each changeset.
Mozilla uses a pushlog which just tracks who pushed what. This lets you look in the commit history on the server (but only there) to see who pushed what group of changesets, giving you a better paper trail than you normally get. This can also be provided by changegroup notifications, if you include the guy who did the push in the email (this is what Python will do once their conversion is done).
So these are the technical solutions. On the other hand, think about this some more: you've already given a group of people push access to your central repositories. If they want, they can muck about with your tree already. If you trust them to push stuff into your central tree, can't you also trust them to have the best intentions about putting their own names on their changesets?