我目前在subversion中的一个组织良好的存储库下收集了我的大部分工作
当另一个人（比如X）需要在子项目上进行协作时，比如/path/to/my/subproject，我可以简单地授予X在该特定路径中读/写的权限。
从我的角度来看，我仍然拥有结构良好的存储库，除了修改一些简单的权限以便为X工作之外不需要做任何其他事情 - 从X的角度来看，他只能访问相关部分。每个人都很开心。
在像git或Mercurial这样的分布式VCS中，似乎每个存储库都提供了所有访问权限 因此，我没有看到如何在这些系统中获得如上所述的类似功能。如果X人突然需要访问原始存储库的某些部分，我似乎必须创建一个全新的存储库 此外，如果另一个人，比如Y，在X可以访问的路径中需要其他访问权限，我就有问题。
我可以在分布式VCS中获得与我目前在subversion中具有差异化访问权限的类似功能吗？如果是这样，怎么样？
答案 0 :(得分：2)
另一个选择是添加authorization层Gitolite。
它具有授权用户的设置：
但更常见的是，是的，一个项目通常等同于一个回购，以便“组件”（“连贯的文件组”）独立于其他组件自行发展。
然后，您可以通过submodules将这些回购加入一个父回购中。
“Distributed Version Control Systems and the Enterprise - a Good mix?”中解释了缺少身份验证和授权。
答案 1 :(得分：1)
这在git或我所知道的任何其他DVCS中是不可能的。 DVCS的想法是分散一切。这带来了存储库没有中央身份验证的事实。如果joe克隆你的回购，他可以完全访问整个回购。现在你可以限制你进入你的存储库的内容，但是他可以用他的任何东西做任何事情。
有像Gitolite这样的第三方解决方案可以让你关闭来实现你想要的行为，但这需要你设置一个服务器并跟踪密钥。这可能是值得的
关键是，据我所知， ，没有办法限制对存储库子目录的读访问权限。写入可以在Gitolite中处理，也可以选择性地执行git fetch，但一旦用户克隆了git存储库，他们就可以完全控制整个存储库
来自Gitolite手册：
- 在回购级别控制的读取访问权限
- 在分支/标记/文件/目录级别控制的写入访问权限，包括谁可以回滚，创建和删除分支/标记