大公司如何处理Mercurial？

Question

我正在调查如何将源代码管理从SVN迁移到Mercurial。我不确定如何处理的一件事是提交中的用户名。从我所看到的情况来看，没有办法强制HG用户使用特定的用户名，即使在Mercurial.ini中指定，用户也可以在提交中使用 -u 标志覆盖它。 hg commit 。

公司如何处理这个问题？没有什么可以阻止开发人员A在他的存储库中作为开发人员B提交某些东西，然后将其推送给其他人。

感谢。

Answer 1

我不会说我们的公司很大（4位开发人员），但到目前为止我们从来都不是一个问题。在我的搜索中，我还没有看到任何阻止这种行为的方法。我想这归结为您的开发人员之间的信任问题。

无关，我们大约两年前成功地从SVN迁移到Mercurial，所以我可以回答你的其他问题。

---

编辑：一个想法：

我不确定您是如何计划设置拓扑的，但我们有一台服务器作为我们所有存储库的中央存储库。可以在开发人员之间推动更改（绕过中央服务器），但我们从不这样做。我们总是在本地提交，然后从/向中央服务器推/拉。此外，我们使用https和Windows身份验证来验证此中央服务器。

如果您计划进行类似的操作，可以在服务器上创建一个钩子（请参阅repository events）（可能是precommit事件），以验证每个提交中的用户名被推送与来自Web服务器的经过身份验证的用户相同。

不确定这是否有效，但听起来似乎是合理的。

Answer 2

另一次尝试

伪CVCS工作流中基于路径的ACL

如果您将使用“受控制的无政府状态”工作流程（p2p通信不受控制，已确认且受信任且单一权威来源是常见的推送目标），您可以使用“每个开发者分支”范例。即，在中央仓库中使用ACL extension时，以下限制适用：

• 没有人可以推送默认分支
• 每个开发人员只能在他的个人分支中推送（在任何名称下，名称均代表什么，跟踪的auth-data是分支名称）
• 只有受信任的合并才能使用repo-Central（将dev-branches合并为默认值，NO rebase |在dev-branches中不重写历史记录）
• 默认分支中的每个合并集都包含身份验证部分 - 源分支

签署分支机构

如果您无法信任（并且必须不信任）提交中的用户名，您可以信任强大的加密。 Mercurial至少有两个扩展，允许数字签名提交，从而在两种情况下提供有关作者身份的准确（一般情况，请参见下面的注释）信息

• Commitsigs Extension Wiki和Signing Mercurial Changesets on Windows mini-HowTo足以理解和展示开始的所有方面。亲：没有额外的签名提交，你不能（按设计）签署旧的历史提交。 Contra：所需命令的输出不太好（请参阅Damian的日志和verifysigs帖子中的截图），因为它是GnuPG（没有PKI），理论上可以为任何名称 - 电子邮件创建和使用密钥对，只有“额外” “比较将为一个用户显示两个不同的键
来自wiki的
• GPG extension和Approval Reports作为快速入门。 Pro：可以使用pgp-keys或openssl-certs（TBT !!!）（其中openssl表示发布证书的一个公司来源），sigcheck命令的更具可读性和信息性的输出。禁忌：

  

将更改提交到工作副本的根目录中的.hgsigs文件   因此需要进行额外的更改。这样做   不可能签署所有变更集。 .hgsigs文件也必须是   合并分支时像合并任何其他文件一样合并。

最后文件可以被恶意用户手动修改为WC中的任何其他文件

编辑和修正错误 Openssl可用于Commitsigs，而不是GPG扩展