我对允许使用身份验证部分进行分布式开发的系统感兴趣。 这是什么意思？
好的，让我们拿SVN，SVN跟踪修改并不关心谁提交，只要你有权提交，你就可以真实地提交到存储库中的任何部分。我的系统在哪里发挥作用？能够对访问控制进行粒化，并为环境提供类似感觉的堆栈溢出。
在我描述的系统中，我们有4个用户Bob，Alice，Dan，Joe。 Bob是一个受管理的项目，Alice和Dan是Bob下的程序员，Joe是互联网上的随机程序员，希望提供帮助。理想情况下，在此系统中，Bob可以提交任何更改，并且不需要批准。 Alice和Dan可以承诺他们的分支机构或分支机构，但是对主干的承诺需要Bob的批准 这是Joe进来的地方，想要帮助，但是，你只是不想给他王国的钥匙，所以在我的系统中你会设置一个“低用户”帐户。 Joe所做的任何提交都需要得到Dan，Alice或两者的批准。但是，在系统中，Joe可以构建“Karma”，经过如此多的批准后，只需要其中一个程序员批准，然后最终不需要批准。
这是否有意义，你知道这样的系统是否存在吗？或者我甚至疯狂地认为这样的系统/环境是可能的？
答案 0 :(得分：2)
任何体面的分布式版本控制系统，如Git或Mercurial，都可以做到这一点。有权推送的人可以推送，其他人则必须发送拉取请求。缺少的唯一功能是自动构建您称之为“Karma”的内容。
这就是大多数开源项目的运行方式。
答案 1 :(得分：1)
嗯......有意思的祝福......
我们来看看。你可以做3个分支：
Bob可以在Final中提交。 Alice和Dan可以在Development中提交，Joe可以在Unsafe中提交。
批准实际上是从较低分支到较高分支的变更合并。例如：Joe在Development分支中由Alice或Dan合并代码时获得批准。同样，Alice和Dan的批准是由Bob在Final分支中合并他们的代码。
因为Karma有点复杂。您可以编写一个脚本，该脚本将不时检查一个用户的合并（批准）数量。当超过某个阈值时，用户将被提升（该脚本使他可以访问更高的分支）。
答案 2 :(得分：0)
您可以为subversion设置基于目录的权限，这可以缓解您在Alice和Dan中提到的绝大多数问题。
大多数项目处理Dan案件的方式是允许他提交补丁，然后由主管提交。
答案 3 :(得分：0)
总是需要提出一个问题：为什么您的解决方案比现有解决方案更好？
例如，为什么不使用分布式系统并让随机用户推送给可以在必要时提取这些更改的人。随着时间的推移，如果开发人员证明自己，只需让他作为管理员访问。
我知道将所有这些都自动化会很酷，但提交源代码并不经常发生，以至于管理员无法管理手动添加人员。