================
Subversion之路
================
----------------------------
實現(xiàn)精細的目錄訪問權限控制
----------------------------
:作者: 鄭新星
:聯(lián)系: zhengxinxing <AT> gmail <DOT> com
:狀態(tài): 正稿
:版本: 1.0
:修訂: $Id: The.Road.to.Subversion_authz.rst 1749 2006-12-05 08:05:59Z zhengxinxing $
:版權: 作者保留對本文的一切修改、發(fā)布等權力。任何人想要轉載本文部分或全部內容時,必須保留包括作者、聯(lián)系、狀態(tài)、版本、修訂、版權,共六項信息,并給出出處。對本文的參考引用,則不受限制。
:關鍵詞: Subversion 目錄訪問 權限
:獻辭:
僅以本文,獻給中國廣大的自由軟件愛好者們
:摘要:
本文從一個實際的例子入手,介紹了如何利用 Subversion 自帶的目錄管理功能,來實現(xiàn)對項目目錄的精細訪問權限的控制。同時描述了在配置的過程中,需要注意的一些地方,如對中文的處理等。
.. section-numbering::
.. contents:: 目 錄
:backlinks: top
前言
====
Subversion 權限簡介
-------------------
在 Subversion 的使用當中,存在“認證”、“授權”兩個概念。認證,即 authentication,是指用戶名與密碼的認證。授權,即 authorization ,是指某用戶對某個目錄是否具備讀、寫權限的一種審核。這兩者配合作用,就組成了 Subversion 的整個帳戶管理體系。
在實際的工作當中,我們有時候會遇見需要控制項目目錄的訪問權限的情況,比如說對項目的一些關鍵模塊進行限制,僅允許少數(shù)授權人士才可以修改等。由于項目的目錄本身就是作為版本庫的一個部分被 Subversion 所收管,所以我們無法利用操作系統(tǒng)的帳戶權限體系,來實現(xiàn)授權控制。因此,這個問題就只有讓svn自己來解決了。
Subversion 提供了面向目錄的帳戶權限管理功能,通過它,我們就可以很精確地實現(xiàn)項目目錄的訪問控制。不過在 1.2 及其以前的版本,我們只能利用 mod_authz_svn.so 模塊,結合 Apache 服務器來實現(xiàn)目錄訪問控制,這對于對 Apache 的配置與使用不是很熟悉的人來說,就不是很方便了。而Subversion終于在 1.3 版本上,在 svnserve.exe 服務器里面添加了這一功能,方便了很多人。
其他信息
--------
本文面向那些 Subversion 的管理員,或者任何對 Subversoin 有興趣的人們。本文假定讀者對Subversion有一定的了解,因此不打算對所有涉及到的安裝、使用,做一個細節(jié)性的描述。若對于文章中描述的其他細節(jié)方面有所疑問,請訪問“參考文獻”一節(jié)里面的參考資料。如果你對本文任何地方有什么意見,或者發(fā)現(xiàn)本文有著大大小小的錯誤,請聯(lián)系 zhengxinxing <AT> gmail <DOT> com 。
本文是基于 Subversion 1.3.2、MS Windows 2003 Server Edition 平臺來編寫的,且 Subversion 服務器是利用 svnserve.exe 來架設的。不過,本文講述到的絕大多數(shù)內容,都是不僅與操作系統(tǒng)平臺無關,而且與是采用 svnserve(.exe) 還是使用 Apache 來作為 Subversion 服務器也基本無關。因此為免羅嗦,本文就以 svnserve(.exe) 為例進行描述,而略過 Apache 服務器相關的內容,有興趣的讀者可以參考其他文章來在 Apache 服務器下實現(xiàn)類似的功能。
本文是利用 reST 格式來編寫的,如果你對它感興趣,請訪問 http://docutils.sourceforge.net/rst.html 。如果想要看到更好的html格式,你可以通篇復制本文到一個文本文件里,然后利用 docutils 的 rst2html.py 腳本編譯它,當然,首先你必須安裝 python。
本文的獲得方式:
- 原始發(fā)布點: http://iusesvn.com/bbs/thread-6-1-1.html
- 完整源文件,請利用 svn 命令來獲取,命令為 ``svn co svn://cvs.woodpecker.org.cn/woodpecker/zqlib/tangle/michael.zheng/road2svn``
- HTML版式文件,請訪問 http://zhengxinxing.googlepages. ... bversion_authz.html (推薦) 或 http://swjr.blog.com.cn/archives ... version1authz.shtml
致謝
====
非常感謝 iusesvn.com 站的站長 PCplayer ,他在本文編寫過程中,給我提出了很多寶貴的意見與建議。
感謝 woodpecker.org.cn 提供的 Subversion 空間,讓更多的人可以通過 svn 獲得本文件。
感謝 google 公司提供的免費主頁空間,讓我可以放置完全定制的 HTML 文件。
實戰(zhàn)
====
本章先直接給出需求及其最終的結果,如果你覺得對配置有什么疑問,或者看不懂,請不要著急,我會在后面的章節(jié)詳細描述的。
背景假設
--------
廈門央瞬公司是一家電子元器件設備供應商,其中有個ARM部門,專門負責ARM芯片的方案設計、銷售,并在北京、上海各設立了一個辦事處。對于工作日志,原先采用郵件方式發(fā)給經理,但是這種方式有個缺點,那就是不具備連續(xù)性,要看以前的日志必須一封一封郵件去查看,很麻煩。于是就想到利用 Subversion, 讓員工在自己電腦上編輯日志,然后利用svn傳送回來,既方便員工自己編寫日志,又方便對日志的歸檔處理,而且提交日志的時候只需要執(zhí)行一下 svn commit 即可,比發(fā)送郵件還要簡單的多。
- svn服務器相關信息
- 服務器地址: 192.168.0.1
- 服務器OS: MS Windows 2000 Server Edition 中文版
- 用于存放日志的代碼庫本地目錄: ``D:\svn\arm``
- arm部門文檔的目錄結構如下::
arm 部門名稱
├─diary 工作日志目錄
│ ├─headquarters 總部工作日志目錄
│ ├─beijing 北京辦日志目錄
│ └─shanghai 上海辦日志目錄
├─ref 公司公共文件參考目錄
└─temp 臨時文件目錄
- 人員情況
- morson,公司總經理,不習慣使用電腦,更喜歡傳統(tǒng)的紙與筆,以及面對面的交流
- michael,arm事業(yè)部的部門經理,沒事的時候喜歡弄點兒新技術,用svn來管理日志,就是他想出來的主意
- scofield,北京辦人員,老員工,為人油滑難管
- lincon,上海辦人員,老員工,大老實人一個
- linda,總部協(xié)調員、秘書,文筆不錯,長得也不錯
- rory,單片機技術員,技術支持
- 訪問權限需求分析
- 允許總經理、部門經理讀取所有文件。順便給他們開放寫權限,以便體現(xiàn)對他們職位的尊重,雖然對于某些文件來說,他們若擁有“寫”權限其實也沒什么用處
- 除部門經理外,所有其他人員,均只能看到本辦事處人員工作日志
- 不允許匿名訪問
- ref目錄只允許經理和秘書讀寫,對其他人只讀
- temp目錄人人都可以隨意讀寫
使用 svnserve.exe 作為 Subversion 服務器
----------------------------------------
本節(jié)描述如何利用 svnserve.exe 來作為代碼庫服務器端,實現(xiàn)上述功能。至于另外一種代碼庫服務器端,即利用 Apache 結合 mod_dav_svn.so 來實現(xiàn)的代碼庫服務器端,由于其對于本文敘述的內容“實現(xiàn)精細的目錄訪問權限控制”而言,與前者沒有太大的區(qū)別,故而略過不提。它們二者只是在初次安裝、配置方面存在一些不同,有興趣的讀者,可以參考其他文檔,重新實驗下述步驟。
啟動 Subversion 服務
````````````````````
在服務器端,打開一個命令行窗口,用CD命令進入 Subversion 安裝目錄下的 bin 目錄,運行如下指令::
svnserve -d -r d:\svn
其中的 -d 參數(shù)表示 svnserve.exe 將會作為一個服務程序運行在后臺,而 -r 參數(shù)表示將 ``D:\svn`` 目錄指定為代碼庫的根目錄。這樣,當客戶端使用類似 svn://192.168.0.1/foo 這樣內容的 URL 來訪問服務器時候,其所訪問到的真實代碼庫,其實就是 ``D:\svn\foo``
用上述命令行方式啟動的 svn 服務有個小缺點,就是在本試驗過程中,服務器端必須要一直開著那個運行了上述命令的DOS窗口,不能關閉它。如果不想看到這個窗口,可以將 svnserve 安裝成 windows 的一個 services,安裝方式請參考其他文章。
建立代碼庫
``````````
在服務器端的 ``D:\svn`` 目錄下,建立一個名為 arm 的代碼庫,命令如下::
D:\svn>svnadmin create arm
使用上述命令之后,如果不出問題的話,在 ``D:\svn`` 目錄下就會多出一個叫做 ``arm`` 的目錄,其下具備 conf、dav、hooks、locks、db 等子目錄或文件,此即 **一個名為arm的代碼庫** 。從此,通過 ``svn://192.168.0.1/arm`` 這樣的 URL,我們就可以對這個代碼庫進行訪問了。接下來就要進入本文的正題了,也就是權限配置部分了。
其實進入 ``arm\conf`` 目錄你就會發(fā)現(xiàn),它下面已經存在三個寫了一些幫助信息和示例的配置文件,以幫助用戶盡早掌握其配置方法。這三個默認的配置文件分別是 svnserve.conf、passwd、authz 。其中后兩者沒有后綴,對于 windows 系統(tǒng)的用戶來說,看起來總是有些怪異,所以在接下來的章節(jié)里面,我將它們兩個都給添加了個 conf 后綴,以便管理。
編輯代碼庫基礎配置文件
``````````````````````
在服務器端,編輯代碼庫的 ``arm\conf\svnserve.conf`` 文件,如下::
[general]
password-db = passwd.conf
anon-access = none
auth-access = write
authz-db = authz.conf
管理用戶帳號
````````````
在服務器端,新建 ``arm\conf\passwd.conf`` 文件,如下::
[users]
morson = ShowMeTheMoney
michael = mysecretpassword
scofield = hellolittilekiller
lincon = asyouknows111
rory = 8809117
linda = IlikeWorldCup2006
建立目錄訪問權限控制文件
````````````````````````
在服務器端,新建 ``arm\conf\authz.conf`` 文件,內容如下::
[groups]
g_vip = morson
g_manager = michael
g_beijing = scofield
g_shanghai = lincon
g_headquarters = rory, linda
g_docs = linda
[arm:/]
@g_manager = rw
* = r
[arm:/diary/headquarters]
@g_manager = rw
@g_headquarters = rw
@g_vip = r
* =
[arm:/diary/beijing]
@g_manager = rw
@g_beijing = rw
@g_vip = r
* =
[arm:/diary/shanghai]
@g_manager = rw
@g_shanghai = rw
@g_vip = r
* =
[arm:/ref]
@g_manager = rw
@g_docs = rw
* = r
[arm:/temp]
* = rw
導入代碼
````````
在客戶機 ``F:\temp`` 目錄下,建立好前述“背景假設”一節(jié)中描述的目錄結構,然后用命令 ``F:\temp>svn import arm svn://192.168.0.1/arm --username michael --password mysecretpassword`` 導入整個目錄結構。
這條指令的精確意思是,將 arm 目錄下面的所有東西,導入到那個名叫 arm 的代碼庫中去。如果你不指定源目錄,則 svn 會默認將當前目錄作為源目錄。比如說,你處于 ``F:\temp`` 目錄下的時候,直接執(zhí)行 ``svn import svn://192.168.0.1/arm`` ,那么當你取出你的代碼的時候,你會發(fā)現(xiàn),居然多了一層名為 arm 的目錄。結果,你就必須使用類似 ``svn://192.168.0.1/arm/arm`` 這樣怪異的URL,才能夠正確訪問到你的代碼們。
這一點粗看好像不是特別重要,不過聯(lián)想到前述的目錄授權規(guī)則,可都是按照標準的項目目錄結構來設計的。突然之間,你項目的根目錄之上,多出了一個名為 arm 的目錄,那么我們的所有目錄授權規(guī)則,基本上都要全部改過了,否則除了根目錄,你永遠會得到一個莫名其妙的“access denied”。由于 Subversion 在這一步驟上的界面不夠人性化,因此這是初學者很容易弄混的地方之一。
測試
````
在服務器上,打開一個 DOS Prompt 窗口,輸入如下指令::
svn co svn://127.0.0.1/arm --no-auth-cache --username rory --password 8809117
我們應該得到如下目錄結構::
arm
├─diary
│ └─headquarters
├─ref
└─temp
然后修改ref目錄下任意文件并提交,服務器將會報錯“Access denied”,Bingo!
深入
====
本章將詳細介紹前一章所涉及的兩個配置文件, svnserve.conf 和 authz.conf,通過對配置逐行的描述,來闡明其中的一些細節(jié)含義。除此之外的其他配置、安裝等內容,不是本文重點,讀者若有什么疑問,請參考后面“參考文獻”中列出的一些文檔。
這里首先要注意一點,任何配置文件的有效配置行,都 **不允許存在前置空格** ,否則程序可能會出錯,給你一個 ``Option expected`` 的提示。也就是說,如果你直接從本文的純文本格式中拷貝了相關的配置行過去,需要手動將前置的4個空格全部刪除。當然了,如果你覺得一下子要刪除好多行的同樣數(shù)目的前置空格是一件苦差使,那么也許 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 三種值,你如果想實現(xiàn)一些特殊的值,比如說“read-once”之類的,建議你自己動手改源代碼,反正它也是自由軟件::
anon-access = none
auth-access = write
接下來就是最關鍵的一句呢,它告訴 svnserve.exe,項目目錄訪問權限的相關配置是放在 authz.conf 文件里::
authz-db = authz.conf
當然,svn 1.3.2 引入本功能的時候,系統(tǒng)默認使用 authz 而不是 authz.conf 作為配置文件。不過可能由于鄙人是處女座的,據(jù)說有著強烈的完美主義情結,看著 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個用戶分組,分組名稱統(tǒng)一采用 ``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事業(yè)部的經理才能修改,其他人都只能眼巴巴的看著::
[arm:/]
@g_manager = rw
* = r
- ``[arm:/]`` 表示這個目錄結構的相對根節(jié)點,或者說是 arm 項目的根目錄。其中的 arm 字樣,其實就是代碼庫的名稱,即前面用 svnadmin create 命令創(chuàng)建出來的那個 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`` 目錄下的文件。因為雖然我們并沒有設置這個目錄的父目錄權限,可是默認的規(guī)則使得 ``/diary`` 目錄的權限與根目錄完全一樣,從而讓其余帳號獲得對 ``/diary/headquarters`` 目錄的 r 權限。所以簡單來說, ``* =`` 這一句的目的,就是割斷權限繼承性,使得管理員可以定制某個目錄及其子目錄的權限,從而完全避開其父目錄權限設置的影響。
- 之所以這兒需要將 ``@g_vip = r`` 一句加上,就是因為存在上述這個解釋。如果說你沒有明確地給總經理授予讀的權力,則他會和其他人一樣,被 ``* =`` 給排除在外。
- 如果眾位看官中間,有誰玩過防火墻配置的話,可能會感覺上述的配置很熟悉。不過這里有一點與防火墻配置不一樣,那就是各個配置行之間,沒有 **先后順序** 一說。也就是說,如果我將本段配置的 ``* =`` 這一行挪到最前面,完全不影響整個配置的最終效果。
接下來我們看看這一段::
[arm:/ref]
@g_manager = rw
@g_docs = rw
* = r
這里的主要看點,就是 g_docs 組里面包含了一個 linda 帳號,她也同時在 g_headquarters 組里面出現(xiàn),這就意味著, linda 將具備對 ``/ref`` 和 ``diary\headquarters`` 兩個目錄的讀寫權限。
authz.conf 之目錄表示法
-----------------------
在前面的描述中,我們都采用 ``[repos:/some/dir]`` 這樣的格式來表示項目的某個目錄,比如上一小節(jié)中的 ``[arm:/diary/headquarters]`` 。而實際上,Subversion 允許你采用 ```[/some/dir]`` 這樣的格式,即不指定代碼庫的方式來表示目錄,此時的目錄就匹配所有項目。
對于使用 svnserve 的用戶來說,只有當 svnserve 運行的時候使用了 ``-r`` 參數(shù),并且讓多個代碼庫共享同一個目錄權限文件(即 authz.conf 或 authz)時,不指明代碼庫名稱才有可能惹麻煩。一般情況下,我們對每個代碼庫都會獨立使用配置文件,畢竟每個項目的目錄結構,都有很大不同,混在一起意義不大。因此一般來說,為簡潔起見,都可以不指明代碼庫名稱。本文全都指明了代碼庫名稱,主要是為了將來擴展成同一個配置文件,以方便配合 Apache 服務器。
對于使用 Apache 的用戶來說,它們二者可有著很大的不同,因為此時往往習慣于使用一個公共的目錄權限配置文件。如果你使用了 SVNParentPath 指令,則指定版本庫的名字是很重要的,因為假若你使用后者,那么 ``[/some/dir]`` 部分就會與所有代碼庫項目的 ``[/some/dir]`` 目錄匹配。如果你使用 SVNPath 指令,則這兩種表示方式就沒有什么區(qū)別了,畢竟只有一個版本庫。
authz.conf 的其他注意點
-----------------------
1. 父目錄的 ``r`` 權限,對子目錄 ``w`` 權限的影響
把這個問題專門提出來,是因為在1.3.1及其以前的版本里面,有個bug,即某個帳號為了對某個子目錄具備寫權限,則必須對其父目錄具備讀權限。因此現(xiàn)在使用了1.3.2及其更高的版本,就方便了那些想在一個代碼庫存放多個相互獨立的項目的管理員,來分配權限了。比如說央舜公司建立一個大的代碼庫用于存放所有員工日志,叫做 diary,而arm事業(yè)部只是其中一個部門,則可以這樣做::
[diary:/]
@g_chief_manager = rw
[diary:/arm]
@g_arm_manager = rw
@g_arm = r
這樣,對于所有arm事業(yè)部的人員來說,就可以將 svn://192.168.0.1/diary/arm 這個URL當作根目錄來進行日常操作,而完全不管它其實只是一個子目錄,并且當有少數(shù)好奇心比較強的人想試著 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 目錄,包括刪除、 **改名** ,和 **新增** 。
也就是說,如果你在項目初期創(chuàng)建目錄時候,一不小心寫錯目錄名稱,比如因拼寫錯誤寫成 dairy,以后除非你改動 authz.conf 里面的這行設置,否則無法利用 svn mv 命令將錯誤的目錄更正。
4. anon-access 屬性對目錄權限的影響
你想將你的代碼庫開放給所有人訪問,于是你就開放了匿名訪問權限,在 svnserve.conf 文件中添加一行: ``anon-access=read`` 。可是對于部分目錄,你又不希望別人看到,于是針對那些特別目錄,你在 authz.conf 里面進行配置,添加了授權訪問的人,并添加了 ``* =`` 標記。你認為一切OK了,可是你缺發(fā)現(xiàn),那個特別目錄卻無法訪問了,總是提示 ``Not authorized to open root of edit operation`` 或者 ``未授權打開根進行編輯操作`` 。你再三檢查你配置的用戶名與密碼,確認一切正確,還是無法解決問題。
原來,Subversion 有個小 bug ,當 ``anon-access=read`` 并且某個目錄有被設置上 ``* =`` 標記,則會出現(xiàn)上述問題。這個 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 文件頭部用于指明高低字節(jié)排列順序的幾個字符,通常是 ``FF FE`` ,而將之用 UTF-8 編碼之后,就是 ``EF BB BF`` 。由于 UTF-8 文件本身不存在字節(jié)序問題,所以對 UTF-16 等編碼方式有重大意義的 BOM,對于 UTF-8 來說,只有一個作用——表明這個文件是 UTF-8 格式。由于 BOM 會給文本處理帶來很多難題,所以現(xiàn)在很多軟件都要求使用不帶 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 呢?我不知道,畢竟我也只是一個普通用戶,不是開發(fā)人員。如果你感興趣,并且英文夠好的話,不妨參考一下這個討論: http://subversion.tigris.org/ser ... ers&msgNo=51334
參考文獻
========
- Subversion官方文檔, http://svnbook.red-bean.com
- Subversion 1.3變更記錄, http://subversion.tigris.org/svn_1.3_releasenotes.html
- Subversion FAQ, http://subversion.tigris.org/faq.html
- UTF-8 常見問題, http://unicode.org/faq/utf_bom.html
歷史軌跡
========
- 2006.06.04, v0.1
* 在 http://iusesvn.com/bbs 首次發(fā)布
- 2006.07.07, v0.4
* 加入 www.woodpecker.org.cn 的 OBP 項目
- 2006.10.11, v0.5
* 修正部分錯誤,調整部分章節(jié)順序
- 2006.12.05, v1.0
* 添加“權限簡介”一節(jié)
* 調整“實戰(zhàn)”章的章節(jié)順序,添加一些說明,使之更具可讀性
* 刪除一些與 apache 服務器相關的說明
* 添加“目錄表示法”一小節(jié)
* 重寫了“authz.conf 之項目子目錄”一小節(jié)
posted on 2007-10-12 15:31
聶文龍 閱讀(371)
評論(0) 編輯 收藏 引用 所屬分類:
軟件應用