是否有“双用户签到”源代码管理系统?

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

一般来说,我认为这更多的是关于您如何组织特定工具的事情,也就是说,如果一个工具具有帮助支持您需要的工作流的功能,那么显然这将有所帮助。

我相信(尽管现在我正在努力寻找参考资料),有些工具在提交之前就有了停止点的概念,这样开发人员提交了,但在批准之前,这些更改是“保留”的。或者有代码审查工具来为您管理钩子(我很沮丧,因为我读过这些东西,但今天早上找不到)。

一般来说,从我所看到的情况来看,这表明DVC(Mercurial、Git、Bazaar等)可能是最合适的解决方案——审查步骤是向中央存储库推进,这解决了“经常提交”和“提交前审查”之间的冲突。另一种选择——正如建议的那样——是在合并前对开发人员分支进行操作和检查。在这两种情况下,关键问题都是比工具集更具管理性——您需要确保由于无法或缺乏对代码进行审查和集成的意愿,积压不会(潜在的“差”代码)形成。

我在TFS中通过删除目标组的签入权限来完成此操作。他们将保存到搁置集中,并通知一组具有“签入为其他”权限的审阅者。

(这应该是倒数第二个度假胜地,但如果代码如下:

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

是常见的,必须采取措施。最后一步是更换团队中的几个成员,确保新员工接受我们的面试,而不仅仅是离岸地点的经理。)

使用Subversion(例如),这可以通过使用具有不同访问权限的两个分支来实现:

• 您拥有每个人都可以提交(签入)到的分支
• 然后是另一个分支,其中只允许一个(或一些)人进行写访问。然后,这些人可以验证第一个分支上的提交,并在一切正常的情况下将它们合并到第二个分支。

顺便说一句:我可能不推荐这种方法,因为它可能会导致太多的开销。我可能会尝试另一种代码审查/批准方法,例如使用一些工具,例如 ReviewBoard 和整个团队一起进行代码审查(学习/改进)。

Git工具有一个“签准者”的概念,维护人员可以在将补丁合并或应用到他们的“官方”树时使用这个概念,无论这在您的过程中意味着什么。在Linux内核这样的项目中,没有签署,没有集成。你可以使用这个过程。

我不知道有任何一个供应链管理人员会开箱即用地完成这项工作,主要是因为这是一个流程/工作流问题,而不是源代码管理问题。
另外,正如其他人正确地说的那样,阻止定期登记到您的存管处是一件坏事,并且开始破坏一个供应链管理解决方案的重要性。
所以你必须做一些“滚你自己的”的事情,因为只有你知道你想要实现的确切过程。
以下是我的表演方式:
1)每个编码人员创建一个用户分支
2)所有更改都将签入其用户分支,而不会签入主分支
3)编码员要求将其代码升级为MAIN:
i)对代码进行审查(通过手动同步到其用户分支或通过一些代码审查工具(如codecollaborator或crucible)进行审查)
ii)代码标记为“干净”
4)然后,用户将主分支集成到其用户分支,并解决任何合并冲突。
5)然后代码集成到主系统。

这种方法仍有一些问题需要解决,即如果在步骤4和5之间,其他人已经集成到了main,那么步骤4将不得不再次执行,因此您可能需要考虑在主集成步骤上使用单个集成器或具有独占锁。

如果您使用的是性能,另一个选项是使用性能触发器。触发器在服务器上运行,您可以编写任何想要验证变更列表及其描述的脚本。如果您信任他人,则任何在变更列表描述中没有短语“reviewed by:”的变更列表都可能失败。如果你不信任别人,你需要diff的md5由门卫的私钥签名。第二个解决方案更需要编写。