分布式开发系统
我对一个允许使用身份验证件进行分布式开发的系统感兴趣。 我这么说是什么意思？
好吧，让我们以 SVN 为例，SVN 会跟踪修订，并不关心谁提交，只要您有权提交，您实际上可以提交到存储库中的任何部分。我的系统在哪里发挥作用？能够细化访问控制并为环境提供类似 stackoverflow 的感觉。
在我描述的系统中，我们有 4 个用户 Bob、Alice、Dan、Joe。 Bob 是一个项目管理人员，Alice 和 Dan 是 Bob 手下的程序员，Joe 是互联网上的随机程序员，他想提供帮助。理想情况下，在此系统中，Bob 可以提交任何更改并且不需要批准。 Alice 和 Dan 可以提交到他们的分支或一个分支，但提交到主干需要得到 Bob 的批准。
这就是乔进来的地方，想要提供帮助，但是，可以这么说，您只是不想给他王国的钥匙，所以在我的系统中您将设置一个“低用户”帐户。乔所做的任何承诺都需要得到丹、爱丽丝或两者的批准。然而，在系统中，乔可以建立“业力”，在经过如此多的批准提交后，它只需要一位程序员的批准，然后最终不需要批准。
这有意义吗？您知道是否存在这样的系统吗？或者我只是疯狂地认为这样的系统/环境是可能的？
I am interested in a system that allows for distributed development with an authentication piece.
What do I mean by that?
Ok so lets take SVN, SVN keeps track of revisions and doesn't care who submits, as long as you have the right to submit you can submit, really, to any part in the repository. Where does my system come into play? Being able to granulate access control and give a stackoverflow like feel to the environment.
In the system I am describing we have 4 users Bob, Alice, Dan, Joe. Bob is a project managed, Alice and Dan are programmers under Bob and Joe is a random programmer on the internet who wants to help. Ideally in this system, Bob can commit any changes and won't require approval. Alice and Dan can commit to their branches, or a branch, but a commit to the trunk would need approval by Bob.
This is where Joe comes in, wants to help, however, you just don't want to give him the keys to the kingdom just yet so to speak, so in my system you would setup a "low user" account. Any commits that Joe makes would need to be approved by Dan, Alice or both. However, in the system, Joe can build up "Karma" where after so many approved commits it would only need approval by one of the programmers, and then eventually no approval would be necessary.
Does that make sense and do you know if a system like that exists? Or am I just crazy to even think such a system/environment would be possible?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
任何像样的分布式版本控制系统，如 Git 或 Mercurial，都可以做到这一点。那些有推送权限的人可以推送，其他人必须发送拉取请求。唯一缺少的功能是自动构建所谓的“Karma”。
这就是大多数开源项目的运行方式。
Any decent distributed version control system, like Git or Mercurial, can do this. Those with permission to push can push, others have to send pull requests. The only feature missing is the automatic build up of what you call "Karma".
This is how most open source projects run.
嗯...有趣的愿望...
让我们看看。您可以执行 3 个分支：
Bob 可以在
Final中提交。 Alice 和 Dan 可以在Development中提交，Joe 可以在Unsafe中提交。审批实际上就是将下级分支的变更合并到上级分支。例如：当 Alice 或 Dan 在
Development分支中合并 Joe 的代码时，他的代码就会获得批准。同样，对 Alice 和 Dan 的批准是 Bob 在Final分支中合并他们的代码。对于业力来说，情况稍微复杂一些。您可以编写一个脚本来不时检查一个用户的合并（批准）数量。当超过某个阈值时，用户就会被提升（脚本使他可以访问更高的分支）。
Hm... Interesting wishes...
Let's see. You could do 3 branches:
Bob can commit in
Final. Alice and Dan can commit inDevelopmentand Joe can commit inUnsafe.The approval is actually the merging of the changes from a lower branch to a higher one. For example: Joe gets approved when his code is merged by Alice or Dan in the
Developmentbranch. Similarly, the approval for the Alice and Dan is the merging of their code, by Bob, in theFinalbranch.For Karma is a little more complicated. You could write a script that will check from time to time the number of merges (approvals) for one user. When a certain threshold is exceeded, the user gets promoted (the script gives him access to higher branches).
始终需要问的一个问题是：为什么您的解决方案比现有解决方案更好？
例如，为什么不使用分布式系统并让随机用户推送给某人，然后在必要时可以提取这些更改。随着时间的推移，如果开发人员证明了自己，只需授予他管理员访问权限即可。
我知道让所有这些自动化会很酷，但是提交源代码并不经常发生，以至于管理员无法管理手动添加人员。
A question that always needs to be asked is: Why is your solution better than existing solutions?
For instance, why not use a distributed system and have random users push to someone who can then pull those changes in if necessary. Over time, if the developer proves himself, just give him access as an admin.
I know it would be cool to have all this automated, but committing source code doesn't happen so often that an administrator couldn't manage adding people by hand.
您可以为 subversion 设置基于目录的权限，这可以缓解您提到的 Alice 和 Dan 的绝大多数问题。
大多数项目处理 Dan 的情况的方式是允许他提交补丁，然后由主管将其汇总到提交中。
You can set up directory-based permissions for subversion, which alleviates the vast majority of the issues you're referring to with Alice and Dan.
The way most projects handle Dan's case is to allow him to submit patches which are then rolled into a commit by a supervisor.