我正在使用在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時，請始終使用特定修訂版。