本章將詳細介紹前一章所涉及的兩個配置檔案， svnserve.conf 和 authz.conf，通過對配置逐行的描述，來闡明其中的一些細節含義。除此之外的其他配置、安裝等內容，不是本文重點，讀者若有什麼疑問，請參考後面“參考文獻”中列出的一些文件。

這裡首先要注意一點，任何配置檔案的有效配置行，都 **不允許存在前置空格** ，否則程式可能會出錯，給你一個 ``Option expected`` 的提示。也就是說，如果你直接從本文的純文字格式中拷貝了相關的配置行過去，需要手動將前置的4個空格全部刪除。當然了，如果你覺得一下子要刪除好多行的同樣數目的前置空格是一件苦差使，那麼也許 UltraEdit 的“Column Mode”編輯模式，可以給你很大幫助。


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 沒有就是不爽，硬是要改了。

上述的 passwd.conf 和 authz.conf 兩個檔案也可以作為多個程式碼庫共享使用，我們只要將它們放在公共目錄下，比如說放在 ``D:/svn`` 目錄下，然後在每個程式碼庫的 svnserve.conf 檔案中，使用如下語句::

    password-db = ../../passwd.conf
    authz-db = ../../authz.conf

或者::

    password-db = ../../passwd.conf
    authz-db = ../../authz.conf
   
這樣就可以讓多個程式碼庫共享同一個使用者密碼、目錄控制配置檔案，這在有些情況下是非常方便的。


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 這個帳號同時存在“總部”和“文件員”兩個分組裡面，這可不是我老眼昏花寫錯了，是因為 Subversion 允許我這樣設定。它意味著，這個傢伙所擁有的許可權，將會比他的同事 rory 要多一些，這樣的確很方便。具體多了哪些呢？請往下看！


authz.conf 之專案根目錄
-----------------------

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

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

- ``[arm:/]`` 表示這個目錄結構的相對根節點，或者說是 arm 專案的根目錄。其中的 arm 字樣，其實就是程式碼庫的名稱，即前面用 svnadmin create 命令創建出來的那個 arm。

- 這裡的 ``@`` 表示接下來的是一個組名，不是使用者名稱。因為目前 g_manager 組裡面只有一個 michael，你當然也可以將 ``@g_manager = rw`` 這一行替換成 ``michael = rw`` ，而表達的意義完全一樣。

- ``*`` 表示“除了上面提到的那些人之外的其餘所有人”，也就是“除了部門經理外的其他所有人”，當然也包括總經理那個怪老頭

- ``* = r`` 則表示“那些人只能讀，不能寫”


authz.conf 之專案子目錄
-----------------------

然後，我們要給總部人員開放日誌目錄的讀寫許可權::

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

這個子目錄的設定有些特色，因為從需求分析中我們知道，這個子目錄的許可權範圍要比其父目錄小，它不允許除指定了的之外其他任何人訪問。在這段設定中，我們需要注意以下幾點：

- 我敢打賭，設計svn的傢伙們，大部分都是在類 unix 平臺下工作，所以他們總喜歡使用 ``/`` 來標識子目錄，而完全忽視在 MS Windows 下是用 ``/`` 來做同樣的事情。所以這兒，為了表示 ``diary/headquarters`` 這個目錄，我們必須使用 ``[arm:/diary/headquarters]`` 這樣的格式。當然如果你一定要用 ``/`` ，那麼唯一的結果就是，Subversion 會將你的這部分設定置之不理，全當沒看到。

- 這裡最後一行的 ``* =`` 表示，除了經理、總部人員、特別人士之外，任何人都被禁止訪問本目錄。這一行是否可以省略呢？不行，因為 **許可權具備繼承性** ，子目錄會自動擁有父目錄的許可權。若沒有這一行，則所有帳號都可以讀取 ``/diary/headquarters`` 目錄下的檔案。因為雖然我們並沒有設定這個目錄的父目錄許可權，可是預設的規則使得 ``/diary`` 目錄的許可權與根目錄完全一樣，從而讓其餘帳號獲得對 ``/diary/headquarters`` 目錄的 r 許可權。所以簡單來說， ``* =`` 這一句的目的，就是割斷許可權繼承性，使得管理員可以定製某個目錄及其子目錄的許可權，從而完全避開其父目錄許可權設定的影響。

- 之所以這兒需要將 ``@g_vip = r`` 一句加上，就是因為存在上述這個解釋。如果說你沒有明確地給總經理授予讀的權力，則他會和其他人一樣，被 ``* =`` 給排除在外。

- 如果眾位看官中間，有誰玩過防火牆配置的話，可能會感覺上述的配置很熟悉。不過這裡有一點與防火牆配置不一樣，那就是各個配置行之間，沒有 **先後順序** 一說。也就是說，如果我將本段配置的 ``* =`` 這一行挪到最前面，完全不影響整個配置的最終效果。

接下來我們看看這一段::

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

這裡的主要看點，就是 g_docs 組裡麵包含了一個 linda 帳號，她也同時在 g_headquarters 組裡面出現，這就意味著， linda 將具備對 ``/ref`` 和 ``diary/headquarters`` 兩個目錄的讀寫許可權。


authz.conf 之目錄表示法
-----------------------
在前面的描述中，我們都採用 ``[repos:/some/dir]`` 這樣的格式來表示專案的某個目錄，比如上一小節中的 ``[arm:/diary/headquarters]`` 。而實際上，Subversion 允許你採用 ```[/some/dir]`` 這樣的格式，即不指定程式碼庫的方式來表示目錄，此時的目錄就匹配所有專案。

對於使用 svnserve 的使用者來說，只有當 svnserve 執行的時候使用了 ``-r`` 引數，並且讓多個程式碼庫共享同一個目錄許可權檔案（即 authz.conf 或 authz）時，不指明程式碼庫名稱才有可能惹麻煩。一般情況下，我們對每個程式碼庫都會獨立使用配置檔案，畢竟每個專案的目錄結構，都有很大不同，混在一起意義不大。因此一般來說，為簡潔起見，都可以不指明程式碼庫名稱。本文全都指明瞭程式碼庫名稱，主要是為了將來擴充套件成同一個配置檔案，以方便配合 Apache 伺服器。

對於使用 Apache 的使用者來說，它們二者可有著很大的不同，因為此時往往習慣於使用一個公共的目錄許可權配置檔案。如果你使用了 SVNParentPath 指令，則指定版本庫的名字是很重要的，因為假若你使用後者，那麼 ``[/some/dir]`` 部分就會與所有程式碼庫專案的 ``[/some/dir]`` 目錄匹配。如果你使用 SVNPath 指令，則這兩種表示方式就沒有什麼區別了，畢竟只有一個版本庫。


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 denied”，哇，太酷了。


2. 預設許可權

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

    [diary:/]
    @g_chief_manager = rw

改成::

    [diary:/]
    # @g_chief_manager = rw

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



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

若設定了::

    [arm:/diary]
    * = r

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

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


4. anon-access 屬性對目錄許可權的影響

你想將你的程式碼庫開放給所有人訪問，於是你就開放了匿名訪問許可權，在 svnserve.conf 檔案中新增一行： ``anon-access=read`` 。可是對於部分目錄，你又不希望別人看到，於是針對那些特別目錄，你在 authz.conf 裡面進行配置，添加了授權訪問的人，並添加了 ``* =`` 標記。你認為一切OK了，可是你缺發現，那個特別目錄卻無法訪問了，總是提示 ``Not authorized to open root of edit operation`` 或者 ``未授權開啟根進行編輯操作`` 。你再三檢查你配置的使用者名稱與密碼，確認一切正確，還是無法解決問題。

原來，Subversion 有個小 bug ，當 ``anon-access=read`` 並且某個目錄有被設定上 ``* =`` 標記，則會出現上述問題。這個 bug 在當前最新版本上（v1.4）還存在，也許在下一版本內可以被改正吧。

解決的辦法是，在 svnserve.conf 中，將 anon-access 設定成 none 。



改進
====

對中文目錄的支援
----------------

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

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

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

2. 修改程式碼庫的 authz.conf 檔案，將相應目錄逐一改名

3. UTF-8 格式的 authz.conf 檔案，以及 BOM

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

目前常用的一些文字編輯工具中，MS Windows 自帶的“記事本”裡面，“另存為”選單儲存出來的 UTF-8 格式檔案，會自動帶上 BOM 。新版本 UltraEdit 提供了選項，允許使用者選擇是否需要 BOM，而老版本的不會新增 BOM。請各位檢視一下自己常用的編輯器的說明檔案，看看它是否支援這個功能。

對於已經存在 BOM 的 UTF-8 檔案，比如說就是微軟“記事本”弄出來的，我們可以利用 UltraEdit 來將 BOM 去掉。方法是，首先利用“UTF-8 TO ASCII”選單將檔案轉換成本地編碼，通常是GB2312碼，然後再使用“ASCII TO UTF-8(UNICODE Editing)”來轉換到 UTF-8 即可。當然，這麼操作之前，你肯定得先保證，你的 UltraEdit 儲存出來的 UTF-8 檔案的確是不帶 BOM 的。

Subversion 為什麼討厭 BOM 呢？我不知道，畢竟我也只是一個普通使用者，不是開發人員。如果你感興趣，並且英文夠好的話，不妨參考一下這個討論： http://subversion.tigris.org/ser ... ers&msgNo=51334