Question

是否有任何源控制系统需要其他用户“才能”签入之前验证源代码？

我想知道，因为这是确保代码质量很高的一种技术。

更新在答案中一直有关于“分支”的讨论，虽然我觉得分支在那里我认为分支是不同的，因为当开发人员的代码准备好进入主分支时，它应该“检查”。最常见的是，当发生这种情况时，首席开发人员或负责合并到主分支/流的人只需将代码放入主分支，只要它“编译”并且不再进行检查。我想要两个人在早期阶段将他们的名字写入代码的想法，以便它引入一些责任，并且因为代码在早期修复起来更便宜，并且在开发人员的脑海中也是新鲜的。

Answer 1

使用subversion（例如），这可以通过使用具有不同访问权限的两个分支来实现：

您拥有每个人都可以提交（签到）
然后你有另一个分支，只允许一个（或某些）人员进行写访问。然后，如果一切正常，这些人可以验证第一个分支上的提交并将它们合并到第二个分支。

BTW：我可能不会推荐这种方法，因为它可能会导致过多的开销。我可能会尝试另一种代码审查/批准的方法，例如使用ReviewBoard等工具并与整个团队进行代码审核（以学习/改进）。

Answer 2

我在TFS中通过删除目标组的签入权限来完成此操作。他们会保存到货架中并通知一组具有“签入其他”权利的审稿人。

（这应该是倒数第二的假设，但是当这样的代码：

if (expr == false || expr.ToString() == "false") { ...

很常见，必须采取措施。最后一步是取代团队中的几名成员，确保我们采访新员工，而不仅仅是离岸地区的经理。）

Answer 3

试图解决问题的解决方案是FogCreek的Kiln：http://www.fogcreek.com/Kiln/ - 这表明你想要的并不是不合理的。

一般来说，我认为这更多地是关于如何组织有关特定工具的内容，如果工具具有帮助支持您所需工作流的功能，那么显然这将有所帮助。

我相信（虽然现在我正在努力寻找参考资料），有些工具在提交之前有一个停止点的概念 - 所以开发人员提交但是更改是“保持”直到批准。无论是那个还是有代码审查工具来管理你的钩子（我很沮丧，因为我已经读过这些东西，但今天早上找不到它。）

一般来说，从我所看到的，这表明DVCS（mercurial，git，bazaar等）可能是最合适的解决方案 - 审查步骤是推送到您的中央存储库，这解决了“经常提交”和“提交前审核”。另一种选择 - 正如建议的那样 - 是您在开发分支机构上工作并在合并之前进行审核在这两种情况下，关键问题是管理而不是工具集 - 您需要确保积压不会（可能是“差”代码）积累，因为无法或缺乏对代码进行审查和集成的意愿。

Answer 4

git工具有一个'签名'的概念，维护者可以在将补丁或应用补丁应用到他们的“官方”树时使用，无论你的过程中有什么意思。在像Linux内核这样的项目中，没有签收，没有集成。你可以使用那个过程。

Answer 5

我不知道任何开箱即用的SCM，主要是因为这是一个过程/ worflow问题，而不是源控制管理问题。
正如其他人正确地说的那样，不鼓励定期检查你的存放处是一件坏事，并且开始破坏了首先使用SCM解决方案的重点。
因此，只要你知道你想要达到的确切过程，你就会做一些“自己动手”的元素以下是我在perforce中的表现方式：
1）每个编码员创建一个用户分支
2）所有更改都会检入其用户分支，而不会进入主分支 3）编码器请求将其代码提升为main：
i）检查代码（通过同步到他们的用户分支或通过CodeCollaborator或Crucible等代码审查工具手动） ii）代码标记为“干净”
4）用户然后将主分支集成到他们的用户分支并解决任何合并冲突 5）然后将代码集成到main。

使用这种方法还有一些问题需要解决，即如果在步骤4和步骤5之间，其他人已经集成到main，则必须再次执行步骤4，因此您可能需要考虑使用单个集成器或具有独占锁定在主要整合步骤

Answer 6

如果您使用perforce，另一个选择是使用perforce触发器。触发器在服务器上运行，您可以编写要验证更改列表及其描述的任何脚本。如果您信任某人，则可以在更改列表说明中使任何没有“已审核：”的更改列表失败。如果您不信任人，则需要使用网守的私钥对差异的MD5进行签名。第二个解决方案更容易编写。

是否有“双用户登记”源控制系统？

6 个答案: