2

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

企业如何应对这种情况？没有什么可以阻止开发人员 A 作为开发人员 B 在他的存储库中提交某些内容，然后将其推送给其他人。

谢谢。

4

2 回答 2

2

I wouldn't say our company is large (4 developers), but it's never been an issue for us so far. I haven't seen any way to prevent that behavior either in my searching. I guess it comes down to an issue of trust amongst your developers.

Unrelated, we did successfully migrate from SVN to Mercurial about two years ago so I may be able to answer other questions you have.

EDIT: An idea:

I'm not sure how you were planning on setting up your topology, but we have a server that functions as the central repository for all our repos. It is possible to push changes between developers (bypassing the central server), but we never do that. We always commit locally and then push/pull from/to the central server. Additionally, we use https and windows authentication to authenticate with this central server.

If you're planning on having something like this, you could create a hook on the server (see repository events) (maybe the precommit event) that would verify that the user name in each commit being pushed is the same as the authenticated user from the web server.

Not sure if this would work, but it sounds plausable.

于 2012-10-16T17:51:40.043 回答
0

另一次尝试

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

如果您将使用“受控无政府状态”工作流程（p2p 通信不受控制、受限制且受信任且单一权威来源是常见的推送目标），您可以使用“每个开发人员的分支”范式。即 - 在中央存储库上使用ACL 扩展，适用以下限制：

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

签约分行

如果您在提交中不能信任（并且您不能信任）用户名，那么您可以信任强加密。Mercurial 至少有两个扩展，允许对提交进行数字签名，从而提供关于作者身份的准确（一般，见下面的注释）信息，在这两种情况下都有各自的优缺点

  • Windows mini-HowTo 上的Commitsigs Extension Wiki和Signing Mercurial Changesets足够完整，足以理解和演示开始的所有方面。优点：没有额外的签名提交，你不能（按设计）签署旧的历史提交。相反：所需命令的输出不太好（请参阅 Damian 帖子中的屏幕截图以获取日志和验证信息），因为它是 GnuPG（无 PKI），理论上可以为任何名称电子邮件创建和使用密钥对，并且只有“额外" 比较会为一个用户显示两个不同的键
  • 来自 wiki 的GPG 扩展和批准报告作为快速入门。优点：可以使用 pgp-keys 或 openssl-certs (TBT!!!)（其中 openssl 表示已颁发证书的一个公司来源），sigcheck 命令的更具可读性和信息量的输出。反对：

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

最后文件可以被恶意用户手动修改，就像 WC 中的任何其他文件一样

编辑和错误修复 Openssl 可以在 Commitsigs 中使用，而不是 GPG 扩展

于 2012-10-16T19:51:09.627 回答