Question

我有一个svn存储库，使用authz来控制访问。结构如下所示：

├── branches
│   └── bob
├── tags
└── trunk
    └── A
        ├── B
        │   └── README.txt
        └── README.txt

假设authz授予用户对目录A的读取权限，但不授予B，并且在尝试分支A时失败：

[hidden]$ svn copy A ^/branches/bob/A1 -m 'Branching A to branches/bob/A1'
Adding copy of        A
svn: E220001: Commit failed (details follow):
svn: E220001: Access denied

svnserve的日志说

Authorization Failed recursive read /trunk/A

为什么svn有此限制并且有办法解决？为什么它不会在分支时忽略B，就像结帐一样？

如果事实证明这是不可能的，那么使用authz的svn的最佳工作流程是什么？它看起来是不允许分支，唯一的方法是每个人都在干线上工作，但这太愚蠢了。

Answer 1

SVN的初始authz实现没有检查副本上的整个子树，但后来添加到地址this security hole。

所以结论是，SVN的authz从一开始就没有很好的设计，迟早有很多hacky和脏修复进入，最终使你的用例不受支持。恕我直言，一个好的实现应该只是跟踪一个分支的复制位置，并检查源的authz。

我同意您的用例完全有效，Perforce支持基于路径的授权。不幸的是你不能在svn中做到这一点。您可以切换到Perforce，也可以等待improve authz。

Answer 2

您对该用户的子节点B具有拒绝权限，拒绝权限会覆盖读取权限。

当分支A，B不能被跳过时（它在A中，并且，就SVN而言，它是其中的一部分）。这就是为什么你不能这样做的原因。它实际上是一件好事，它会阻止你，因为你通常不想要一个错过源文件夹的分支。

应该没有解决方法，这种行为实际上是有道理的。要使分支操作成功，您需要：

将A移到A
授予用户访问A及其下的所有内容的权限

我确实理解可能存在令人沮丧的情况，但如果B不依赖于A，或者如果某人在A上工作并不关心B或需要访问B - 在这种情况下B不应该真的在A里面。

具有部分读访问权限的分支目录

2 个答案: