分布式 VCS 中的差异化访问权限

发布于 2024-12-07 09:28:56 字数 485 浏览 7 评论 0原文

我目前已经在 subversion 中将大部分工作收集到一个组织良好的存储库中。
当另一个人(例如 X)需要在子项目(例如 /path/to/my/subproject)上进行协作时,我可以简单地授予 X 在该特定路径中读取/写入的权限。
从我的角度来看,我仍然拥有结构良好的存储库,除了修改一些简单的权限以使所有内容都能为 X 工作之外,不需要做任何其他事情 - 从 X 的角度来看,他只需访问相关部分。每个人都很高兴。

然而,在像 git 或 Mercurial 这样的分布式 VCS 中,所有访问权限似乎都是按存储库授予的。
因此,我不知道如何在这些系统中获得如上所述的类似功能。如果 X 突然需要访问我原始存储库的部分内容,我似乎必须创建一个全新的存储库。
此外,如果另一个人(比如 Y)需要 X 有权访问的路径内的其他访问权限,我就会遇到问题。

我能否在分布式 VCS 中获得与当前 Subversion 中类似的功能和不同的访问权限?如果是这样,怎么办?

I have currently collected a large part of my work under a single and nicely organized repository in subversion.
When another person, say X, needs to collaborate on a sub-project, say /path/to/my/subproject, I can simply give X permissions to read/write in that specific path.
From my point of view, I still have the nicely structured repository and doesn't need to do anything else than modify some simple permissions for everything to work for X - and from X's point of view, he has just access to the relevant part. Everybody is happy.

In a distributed VCS like git or Mercurial however, all access seems to be given per repository.
I therefore fail to see how to obtain similar functionality as described above in these systems. It seems that I have to create a whole new repository if person X suddenly needs access to parts of my original repository.
Furthermore, if another person, say Y, needs other access rights within the path that X has access to, I have a problem.

Can I obtain similar functionality with differentiated access rights in distributed VCS's as I currently have in subversion? If so, how?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

朱染 2024-12-14 09:28:57

另一种选择是添加 授权Gitolite这样的层。

它具有授权用户执行以下操作的设置:

但更一般地说,是的,一个项目通常等同于一个存储库,以便该“组件”(“一致的文件集”)能够独立于其他组件自行发展。
然后,您可以通过子模块将这些存储库加入到一个父存储库中。

One other option is to add an authorization layer like Gitolite.

It has settings for authorizing a user to:

But more generaly, yes, one project often equates one repo, in order for that "component" ("coherent set of files") to evolves on its own, independently of others.
You can then join those repos within one parent repo through submodules.

The lack of authentication and authorization is explained in "Distributed Version Control Systems and the Enterprise - a Good mix?".

空城仅有旧梦在 2024-12-14 09:28:57

这在 git 或我所知道的任何其他 DVCS 中是不可能的。 DVCS 的理念是去中心化一切。这带来了存储库没有中央身份验证的事实。如果 joe 克隆了您的存储库,他就可以完全访问整个存储库。现在你可以限制你拉入存储库的内容,但他可以用他的存储库做任何他想做的事。

有像 Gitolite 这样的第三方解决方案可以让您接近您想要的行为,但它需要您设置服务器并跟踪密钥。这可能是值得的

关键是,据我所知,没有办法限制对存储库子目录的读取访问。写入可以在 Gitolite 中处理,也可以通过有选择地进行 git fetch 来处理,但是一旦用户克隆了 git 存储库,他们就可以完全控制整个存储库在他们的机器上。

来自 Gitolite 手册:

  • 在存储库级别控制读取访问
  • 在分支/标签/文件/目录级别控制写入访问权限,包括谁可以倒回、创建和删除分支/标签

This is not possible in git, or any other DVCS that I know of. The idea of a DVCS is to decentralize everything. This carries with it the fact that the repository has no central authentication. If joe clones your repo, he has full access to that entire repo. Now you can limit what you pull into your repository, but he can do anything he wishes with his.

There are 3rd party solutions like Gitolite that would allow you to get close to the behavior you wish, but it would require that you setup a server and track keys. Which may be worth it

The key thing is that, as far as I know, there is no way to limit read access to a sub directory of a repository. Write can be taken care of in Gitolite or by selectively doing your git fetch, but once a user has cloned a git repository, they have full control of the entire repository while it is on their machine.

From the Gitolite manual:

  • Read access controlled at the repo level
  • write access controlled at the branch/tag/file/directory level, including who can rewind, create, and delete branches/tags
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文