1 svnserve.conf

arm\conf\svnserve.conf 文件，是 svnserve.exe 這個服務器進程的配置文件，我們逐行解釋如下。

首先，我們告訴 svnserve.exe，用戶名與密碼放在 passwd.conf 文件下。當然，你可以改成任意的有效文件名，比如默認的就是 passwd:

password-db = passwd.conf

接下來這兩行的意思，是說只允許經過驗證的用戶，方可訪問代碼庫。那么哪些是"經過驗證的"用戶呢？噢，當然，就是前面說那些在 passwd.conf 文件里面持有用戶名密碼的家伙。這兩行的等號后面，目前只允許 read write none 三種值，你如果想實現一些特殊的值，比如說"read-once"之類的，建議你自己動手改源代碼，反正它也是自由軟件:

anon-access = none
auth-access = write

接下來就是最關鍵的一句呢，它告訴 svnserve.exe，項目目錄訪問權限的相關配置是放在 authz.conf 文件里:

authz-db = authz.conf

當然，svn 1.3.2 引入本功能的時候，系統默認使用 authz 而不是 authz.conf 作為配置文件。不過由于鄙人是處女座的，有著強烈的完美主義情結，看著 svnserve.conf 有后綴而 passwd 和 authz 沒有就是不爽，硬是要改了。

2 authz.conf 之用戶分組

arm\conf\authz.conf 文件的配置段，可以分為兩類，``[group]`` 是一類，里面放置著所有用戶分組信息。其余以 [arm:/] 開頭的是另外一類，每一段就是對應著項目的一個目錄，其目錄相關權限，就在此段內設置。

首先，我們將人員分組管理，以便以后由于人員變動而需要重新設置權限時候，盡量少改動東西。我們一共設置了5個用戶分組，分組名稱統一采用 g_ 前綴，以方便識別。當然了，分組成員之間采用逗號隔開:

[groups]
# 任何想要查看所有文檔的非本部門人士
g_vip = morson
# 經理
g_manager = michael
# 北京辦人員
g_beijing = scofield
# 上海辦人員
g_shanghai = lincon
# 總部一般員工
g_headquarters = rory, linda
# 小秘，撰寫文檔
g_docs = linda

注意到沒有， linda 這個帳號同時存在"總部"和"文檔員"兩個分組里面，這可不是我老眼昏花寫錯了，是因為 svnserve.exe 允許我這樣設置。它意味著，這個家伙所擁有的權限，將會比他的同事 rory 要多一些，這樣的確很方便。具體多了哪些呢？請往下看！

3 authz.conf 之項目根目錄

接著，我們對項目根目錄做了限制，該目錄只允許arm事業部的經理才能修改，其他人都只能眼巴巴的看著:

[arm:/]
@g_manager = rw
* = r

• [arm:/] 表示這個目錄結構的相對根節點，或者說是 arm 項目的根目錄
• 這里的 @ 表示接下來的是一個組名，不是用戶名。你當然也可以將 @g_manager=rw 這一行替換成 michael=rw ，而表達的意義完全一樣。
• * 表示"除了上面提到的那些人之外的其余所有人"，也就是"除了部門經理外的其他所有人"，當然也包括總經理那個怪老頭
• * = r 則表示"那些人只能讀，不能寫"

4 authz.conf 之項目子目錄

然后，我們要給總部人員開放日志目錄的讀寫權限:

[arm:/diary/headquarters]
@g_manager = rw
@g_headquarters = rw
@g_vip = r
* =

• 我敢打賭，設計svn的家伙們，大部分都是在 unix/linux 平臺下工作，所以他們總喜歡使用 / 來標識子目錄，而完全忽視在 MS Windows 下是用 \ 來做同樣的事情。所以這兒，為了表示 arm\diary\headquarters 這個目錄，我們必須使用 [arm:/diary/headquarters] 這樣的格式。
• 這里最后一行的 *= 表示，除了經理、總部人員、特別人士之外，任何人都被禁止訪問本目錄。這一行是否可以省略呢？
• 之所以這兒需要將 @g_vip=r 一句加上，就是因為存在上述這個解釋。如果說你沒有明確地給總經理授予讀的權力，則他會和其他人一樣，被 * 給排除在外。
• 如果眾位看官中間，有誰玩過防火墻配置的話，可能會感覺上述的配置很熟悉。不過這里有一點與防火墻配置不一樣，那就是各個配置行之間，沒有 先后順序 一說。也就是說，如果我將本段配置的 *= 這一行挪到最前面，完全不影響整個配置的最終效果。
• 請注意這兒，我們并沒有給 arm\diary 目錄設置權限，就直接跳到其子目錄下進行設置了。我當然是故意這樣的，因為我想在這兒引入"繼承"的概念。
• 權限具備繼承性 任何子目錄，均可繼承其父目錄的所有權限，除非它自己被明確設置了其他的權限。也就是說，在 arm 目錄設置權限后， arm\diary 目錄沒有進行設置，就意味著它的權限與 arm 目錄一樣，都是只有經理才有權讀寫，其他人只能干瞪眼。
• 【 * = 是否可以省略】【用例子引入覆蓋】【單用戶權限的繼承問題】【父目錄權限集成與全面覆蓋問題】

現在來看看

好了，我們現在掌握了"繼承"的威力，它讓我們節省了不少敲鍵盤的時間。可是現在又有一個問題了，

屬性具備覆蓋性質子目錄若設置了屬性，則完全覆蓋父目錄。

5 authz.conf 的其他注意點

1. 父目錄的 r 權限，對子目錄 w 權限的影響

把這個問題專門提出來，是因為在1.3.1及其以前的版本里面，有個bug，即為了子目錄的寫權限，項目首目錄必須具備讀權限。因此現在使用了1.3.2版本，就方便了那些想在一個代碼庫存放多個相互獨立的項目的管理員，來分配權限了。比如說央舜公司建立一個大的代碼庫用于存放所有員工日志，叫做 diary，而arm事業部只是其中一個部門，則可以這樣做:

[diary:/]
@g_chief_manager = rw
[diary:/arm]
@g_arm_manager = rw
@g_arm = r

這樣，對于所有arm事業部的人員來說，就可以將 svn://192.168.0.1/diary/arm 這個URL當作根目錄來進行日常操作，而完全不管它其實只是一個子目錄，并且當有少數好奇心比較強的人想試著 checkout 一下 svn://192.168.0.1/diary 的時候，馬上就會得到一個警告"Access deni"，哇，太酷了。

2. 默認權限

如果說我對某個目錄不設置任何權限，會怎樣？馬上動手做個試驗，將:

[diary:/]
@g_chief_manager = rw

改成:

[diary:/]
# @g_chief_manager = rw

這樣就相當于什么都沒有設置。在我的 svn 1.3.2 版本上，此時是禁止任何訪問。也就是說，如果你想要讓某人訪問某目錄，你一定要顯式指明這一點。這個策略，看起來與防火墻的策略是一致的。

3. 只讀權限帶來的一個小副作用

若設置了:

[arm:/diary]
* = r

則svnserve認為，任何人，都不允許改動diary目錄，包括刪除和改名，和新增。

也就是說，如果你在項目初期創建目錄時候，一不小心寫錯目錄名稱，比如因拼寫錯誤寫成 dairy，以后除非你改動 authz.conf 里面的這行設置，否則無法利用 svn mv 命令將錯誤的目錄更正。

1 對中文目錄的支持

上午上班的時候，Morson 來到 Michael 的桌子前面，說道："你是否可以將我們的北京辦、上海辦目錄，改成用中文的，看著那些拼音我覺得很難受？" Michael 心想，還好這兩天剛了解了一些與 unicode 編碼相關的知識，于是微笑地回答："當然可以，你明天下午就可以看到中文目錄名稱了。"

1. 使用 svn mv 指令，將原來的一些目錄改名并 commit 入代碼庫，改名后的目錄結構如下:

   arm
   ├─工作日志
   │  ├─總部人員
   │  ├─北京辦
   │  └─上海辦
   ├─公司公共文件參考目錄
   └─臨時文件存放處
   

2. 修改代碼庫的 authz.conf 文件，將相應目錄逐一改名

3. 使用 UltraEdit 將 authz.conf 文件轉換成不帶 BOM 的 UTF-8 格式

   將配置文件轉換成 UTF-8 格式之后，Subversion 就能夠正確識別中文字符了。但是這里需要注意一點，即必須保證 UTF-8 文件不包含 BOM 。BOM 是 Byte Order Mark 的縮寫，指 UNICODE 文件頭部用于指明高低字節排列順序的幾個字符，通常是 FFFE ，而將之用 UTF-8 編碼之后，就是 EFBBBF 。由于 UTF-8 文件本身不存在字節序問題，所以對 UTF-16 等編碼方式有重大意義的 BOM，對于 UTF-8 來說，只有一個作用--表明這個文件是 UTF-8 格式。由于 BOM 會給文本處理帶來很多難題，所以現在很多軟件都要求使用不帶 BOM 的 UTF-8 文件，特別是一些處理文本的軟件，如 PHP、 UNIX 腳本文件等，svn 也是如此。

目前常用的一些文本編輯工具中，MS Windows 自帶的"記事本"里面，"另存為"菜單保存出來的 UTF-8 格式文件，會自動帶上 BOM 。新版本 UltraEdit 提供了選項，允許用戶選擇是否需要 BOM，而老版本的不會添加 BOM。請各位查看一下自己常用的編輯器的說明文件，看看它是否支持這個功能。

利用 UltraEdit ，我們可以將 BOM 去掉。方法是，首先利用"UTF-8 TO ASCII"菜單將文件轉換成本地編碼，通常是GB2312碼，然后再使用"ASCII TO UTF-8(UNICODE Editing)"來轉換到 UTF-8 即可。