我正在使用在Windows 7下运行的svnserve 1.4。我想通过使用authz文件来控制用户权限。
我希望在根文件夹被读取保护时将'rw'权限授予子文件夹。我有一个大型存储库，并希望仅为有限的文件子集提供“rw”权限。其他文件夹对用户来说是不可见的。
如果我使用以下配置，则不显示任何内容：
[/root]
group1 =
[/root/A/new/Data]
group1 = rw
[/root/C/Ex/Files]
group1 = rw
如果我改为使用：
[/]
group1 = rw
然后所有文件夹对“group1”都是可见的，这不是我需要的。
另一种选择是做类似
的事情[root/B]
group1 =
[root/c]
group1 =
表示group1不需要的所有子文件夹。不过，我宁愿不必这样做。
答案 0 :(得分：1)
请注意，如果用户没有对文件夹的读取权限，则他们无法访问该文件夹中的任何内容。如果没有读访问权限，Subversion无法知道其中是否存在需要检查权限的文件或文件夹。拒绝读访问将递归隐藏文件夹及其中的所有内容。
如果您发现自己处于需要这种细粒度访问控制的情况，我强烈建议您重新评估您的存储库布局。如果您的/root和/root/A/new/Data等嵌套资源需要如此截然不同的权限，那么它们在回购中的关系很可能并不反映它们在现实中的关系。通常情况下，这样的事情最终会被重新组织成单独的项目（甚至是单独的存储库）而不是嵌套文件夹，因此大多数细粒度的访问控制工作都会大大简化。
如果您无法在不破坏构建脚本等情况下重新组织存储库，那么您可能需要考虑使用Subversion的svn:externals属性。您可以将/root/A/new/Data的内容移动到单独的存储库中，并为group1提供对其的完全访问权限。然后，您可以使用svn:externals将新的存储库路径拖到同一文件夹名称下的/root文件夹中，以便那些有权访问/root的人在svn checkout时看到相同的内容{{1} }}。当子文件夹的内容类似于由外部团队提供的库时，这种工作流程非常有用。您需要让图书馆团队访问图书馆代码（他们通过直接访问图书馆的存储库），但他们不需要访问您的其余代码。
答案 1 :(得分：1)
我正在使用在Windows 7下运行的svnserve 1.4。
很快就不再支持Subversion 1.4了。您可能希望升级到1.7.x或1.6.x版。这些更高版本支持合并跟踪，这是一个很好的功能。升级现有存储库非常简单。
正如其他人所指出的，如果您没有读取文件夹的权限，则无权读取该文件夹的子文件夹。您可以在父文件夹上设置只读权限，但如果您取消读取，则用户无法看到要授予读/写权限的子文件夹。
您可能想重新考虑一下您的存储库布局。将存储库的读访问权授予选定的一组人并不罕见。例如，您可能不希望销售人员阅读您的源代码，但您确实希望您的开发人员。我通常的spiel是基于每个存储库授予读/写权限，然后使用预提交钩子来控制提交能力。有时一个目录包含你甚至不希望所有开发人员都看到的东西（比如你的私钥），只有一小部分开发人员应该看到它。在这种情况下，我将它作为一个单独的存储库。
并非所有希望都失去了。您可以将希望group1访问的目录放在靠近存储库根目录的另一个目录结构中。然后使用svn:externals到您不希望group1中的用户查看的目录。
例如，像这样设置您的存储库：
[/root]
group1=
[/A/new/Data]
group1=rw
[C/Ex/Files]
group1=rw
在结帐svn:externals时，在/root上放置一组A/new/Data以包含C/Ex/Files和/root。
WORD'O WARNING ：使用svn:externals时要小心。如果您将它们指向分支或主干的尖端，即使您标记svn:external，/root仍会发生变化。使用svn:externals时始终使用特定修订版。