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