代码之家 › 专栏 › 技术社区 › Natalie Adams

分布式开发系统

distributed development-environment

Natalie Adams · 技术社区 · 15 年前

我对一个允许使用身份验证块进行分布式开发的系统感兴趣。我这是什么意思?

好吧,那么让我们以SVN为例,SVN跟踪修订,而不关心谁提交,只要您有权提交,您就可以真正地提交到存储库中的任何部分。我的系统在哪里起作用?能够对访问控制进行粒度化,并给环境带来类似stackoverflow的感觉。

在我描述的系统中,我们有4个用户Bob、Alice、Dan和Joe。Bob是一个项目管理者,Alice和Dan是Bob的程序员,Joe是一个随机的网络程序员,他们想帮忙。理想情况下,在这个系统中,Bob可以提交任何更改,不需要批准。Alice和Dan可以提交到他们的分支或分支,但是提交到主干需要Bob的批准。
这就是乔进来的地方,他想帮忙,但是,你只是不想给他这个王国的钥匙而已,可以这么说,所以在我的系统中,你会设置一个“低用户”帐户。乔所做的任何承诺都需要得到丹、爱丽丝或两者的批准。然而,在系统中,Joe可以构建“业力”,在这种情况下,经过这么多批准的提交之后,它只需要一个程序员的批准,最终不需要任何批准。

这有道理吗?你知道这样的系统是否存在吗?或者我是疯了,甚至认为这样的系统/环境是可能的?

4 回复 | 直到 15 年前

foobarfuzzbizz 15 年前

一直需要问的一个问题是:为什么您的解决方案比现有的解决方案更好?

例如,为什么不使用一个分布式系统,让随机用户推送给某个人,然后在必要时将这些更改拉入。随着时间的推移,如果开发人员证明了自己,只需授予他作为管理员的访问权限。

我知道让所有这些自动化是很酷的,但是提交源代码并不经常发生,管理员无法手动管理添加人员。

David M 15 年前

任何像样的分布式版本控制系统,如Git或Mercurial,都可以做到这一点。有推权限的人可以推,其他人必须发送拉请求。唯一缺少的特征是你所谓的“业力”的自动建立。

这就是大多数开源项目的运行方式。

Victor Hurdugaci 15 年前

Hm.…有意思的祝愿…

让我们看看。你可以做3个分支:

决赛
发展
不安全的

鲍勃可以承诺 Final . 爱丽丝和丹可以承诺 Development 乔可以承诺 Unsafe .

批准实际上是将较低分支的更改合并到较高分支的更改。例如:当Alice或Dan在 发展 分支机构。同样,对Alice和Dan的批准是由Bob在 决赛 分支机构。

因为业力有点复杂。您可以编写一个脚本,该脚本将不时检查一个用户的合并(批准)数量。当超过某个阈值时,用户将得到提升(脚本允许他访问更高的分支)。

AvatarKava 15 年前

您可以为Subversion设置基于目录的权限,这可以减轻您在Alice和Dan中提到的绝大多数问题。

大多数项目处理Dan案例的方式是允许他提交补丁,然后由主管提交到提交中。