SVN的Local方式：個人源碼管理的好辦法
出處：http://blog.csdn.net/Raptor/archive/2005/03/18/322889.aspx
SVN、Local方式、個人源碼管理
今天在QQ羣裏，有人在打聽Delphi的VSS插件，於是被我B4了一番。正好我最近試用了SVN，感覺很不錯，於是在羣裏強力推薦，以致於幾乎被認爲是SVN的托兒。-_-|||
事實上SVN的確是我用過的最好的源碼管理工具，雖然我用過的這類工具並不多，只有VSS、CVS和SVN，其它像PVCS、 TeamSource、ClearCase之類的只有耳聞，因爲它們都是商業產品，並且通常用於管理大型的項目，沒有機會試用，所以也不知道它們如何。 VSS是我四年前在公司裏用過的最早的一款源碼管理工具，不過它實在是太一般了，而且也是商業產品。所以除了公司裏工作需要，我自己是不用的。從那公司出 來以後，我試用了CVS，這纔開始對自己的源碼進行管理。作爲OSS圈裏元老級的源碼管理工具，CVS有多強我不用再多說。但是現在SVN這顆新星已經漸 漸要蓋過CVS的光芒了，可見SVN是有自己殺手鐗的。還有一點很重要的就是：它也是一個開源免費的軟件。
SVN全名Subversion。SVN與CVS一樣，是一個跨平臺的軟件，支持大多數常見的操作系統。本文只討論Windows的情況。其官方網站是：http://subversion.tigris.org(tigris是一個和sourceforge類似的開源網站，與sf不同的是，sf提供的CVS服務，而tigris提供的是SVN服務)。
在介紹SVN的應用前，先討論一下源碼管理的一個重要的基本概念：Repository。Repository 就是源碼的集中存放處，所有修改後提交的源碼就是保存在這裏，並在其中記錄所有的修改版本，分支版本，版本合併，以及併發修改處理等。傳統的VSS或 CVS都是採用類似C/S的應用方式，有一個獨立的服務端來做這些工作。而SVN則要靈活得多，它支持三種方式：獨立服務器方式、Web服務器方式（這是CVS所沒有的）和本文將要着重討論的Local方式。
回到主題上。個人源碼管理是我自己提的一個概念，以區別於團隊 開發的源碼管理。本來像VSS、CVS、SVN這樣的工具最主要的功能是用於團隊開發時用的，用於處理源碼修改的版本控制和併發修改衝突。但對於個人開發 來說，就不存在併發修改衝突的問題了。但個人開發又存在一些新的問題：一般個人沒有條件搭一個獨立的服務器來做Repository，所以實際上即使是用 了CVS一類，也是服務端客戶端在一臺機器上，而且也不需要用戶權限管理這樣的功能。但有時又需要在不同的機器間拷貝源碼作開發，這又帶來版本混亂的潛在 風險。而SVN的Local方式可以說是最好的解決方案。
我現在的用法就是：在U盤裏建立Repository，然後在每臺機器上都裝了SVN，這樣我就不需要一臺單獨的Repository服務器，只要在任一臺機器上把U盤插上即具備了完整的版本控制功能。
SVN的安裝和使用。
因爲本文只討論Windows下的Local方式，所以不需要獨立服務器或Web服務器。SVN的客戶端和CVS一樣，也是命令行方式工作。但在Windows平臺下，我們有還別的選擇，這就是易用性很好的一個實現：TortoiseSVN（注意：這是一個獨立於SVN的項目，類似於WinCVS與CVS的關係）。其官方網站是：http://www.tortoisesvn.org，下載其安裝程序：TortoiseSVN-1.1.3-UNICODE_svn-1.1.3.msi（這個文件名是指NT/2k/XP版的）。這個集成發佈包中包含了Local應用所需要的全部內容。如果想要中文版，還可以下載這個中文語言包：LanguagePack_1.1.3_zh_CN.exe（這是簡體中文包，BTW：從進度上看，繁體中文的完成度還要高些:P）。至於其它的如獨立服務器方式，Web服務器方式，命令行方式，Python支持等，都要相應的安裝包提供，可自行參考SVN網站說明下載安裝。
安裝的過程非常簡單，只是安裝完成後必須重啓一下，因爲它要集成到Windows的資源管理器中。這也可以算是SVN的又一個大優點（多 謝mikeshi指出：CVS也有一個TortoiseCVS，這不算是SVN的優點），雖然CVS也有一個WinCVS不錯，但是它畢竟是一個額外的客 戶端，不如TortoiseSVN這麼方便。TortoiseSVN裝好後，只要在資源管理器中任何一個文件夾中點右鍵，即可出現如下圖所示的菜單（我打 了中文包，所以顯示是中文，可以在Settings中選擇任何一種已經安裝的語言包）：
第一步：建立Local Repository
假設現在要開始一個項目，叫做Project1。先在U盤（假設爲U:）建立一個文件夾：u:/svn/project1。然後在這個文件夾上點右鍵，選擇：TortoiseSVN|在此創建文件庫。有兩種方式供選擇，如下圖：
Berkeley數據庫和本地文件系統。本地文件系統方式有點類似於CVS，但實現方式上有所不同。Berkeley數據庫據說是目前最好的嵌入式 數據庫解決方案，TortoiseSVN默認選擇BDB方式，推薦。確定創建後稍等一會即會彈出一個提示窗，說明文件庫創建成功。
第二步：創建工作文件夾
在本地硬盤（如D盤）創建一個工作文件夾：d:/working/project1。然後在這個文件夾上點右鍵，選擇：SVN取出。顯示如下對話框：
其中唯一需要指定的就是文件庫URL，Local方式是使用file協議。確定後顯示如下對話框：
點確定後完成創建工作，在文件夾中看到一個隱藏的文件夾：.svn。其中記錄了工作文件夾的一些必要信息，功能與CVS的CVS文件夾一樣。一個SVN的工作文件夾的圖標上將會多了一個綠色的勾，所有被加入Respository的內容都會在圖標上加上這樣的綠勾，如圖：
第三步：開始寫程序
現在可以在此工作目錄中創建源程序文件或文件夾。在工作文件夾中的任何文件或文件夾（除了.svn文件夾）的右鍵菜單上都會增加一些項目，下圖分別爲工作文件夾、工作文件夾下的子文件夾、工作文件夾中的文件、已經提交的文件的右鍵菜單內容：
從最左邊的菜單和最右邊的菜單上可以看到，SVN/TortoiseSVN支持了CVS的幾乎所有功能，還增加了一些很實用的功能（比如文件/文件夾的重命名，在這CVS裏是最讓人頭疼的問題之一）。這又是SVN的大優點。
如果你的源程序原來就存在，可以立即導入到Repository裏：在你原來的源程序文件夾上點右鍵，選擇TortoiseSVN|導入。即可。不過要注意：最好先在TortoiseSVN|設置裏設定排除/忽略樣式（可以設置文件夾或文件名，支持通配符，區分大小寫！！！），或是先刪除不必要導入的文件。然後再取出（Checkout）到工作目錄即可。
第四步：將寫好的程序提交到Repository
選擇所有要加入的文件和文件夾，然後點TortoiseSVN|加入。將顯示如下對話框（以將本文提交爲例）：
把它們加入Repository，確定後它的圖標上將顯示一個“+”號，表示這個文件已經加入，但還未提交。再在當前文件夾上點右鍵，選擇SVN提交即可。將顯示如下對話框（提交本文，其中的Repository是我實際使用的）
成功提交後，它的圖標上也將顯示一個前面所示的那樣的綠勾。
第五步：日常使用
無非是重複前面的加入/提交等操作。如果在其它機器上使用，則需要重新創建工作目錄，並取出（Checkout）Repository中的源碼。如果同時在多臺機器上使用，則需要使用SVN更新功能來將此工作文件夾中的內容更新爲Repository中的相應版本。
更多的功能請參考聯機幫助及網站提供的其它文檔資料。
最後祝大家都能體會到SVN所帶來的方便和愉快。
SubVersion的權限設置（基於tortoiseSVN客戶端）
出處：http://blog.sina.com.cn/s/blog_4e7a61b50100e2z5.html
這一節中我們重點講述subversion本身的權限設置問題，即使用tortoiseSVN的權限的問題。
以匿名方式對SVN進行操作，也就是不需要輸入用戶名和密碼。對於讀取操作來說，這是可以的，可是對於寫入操作來說就不能隨便允許匿名用戶commit，否則項目會發生嚴重混亂。CVS和SVN除了可以提供操作系統用戶名驗證機制外，還提供了獨立的驗證機制，即不依靠操作系統用戶名，這樣就降低了系統發生侵害的可能。
1）轉到SVN資源庫的目錄：E:/svn/repository，進入conf目錄，打開svnserve.conf文件，大家可以閱讀該文件的內容，會發現實際上該文件就是一個設定SVN認證信息的重要文件，我們在之前已經對該文件進行了操作，增加了匿名用戶的訪問權限。現在我們來增加需要授權才能訪問的信息。
首先將之前匿名可以訪問的部分刪除，只能通過提供用戶名和密碼才能訪問SVN。將anon-access = read與anon-access = write之前增加一個#號，表示註釋掉該部分。將password-db = passwd之前的#號刪掉。這表示用戶的用戶名與密碼信息放置passwd文件中。OK，保存該文件，關閉它。（注意：password-db = passwd中，passwd這個文件跟apache的passwd是不同的，這個只是針對tortoiseSVN訪問而設的權限，，默認路徑是和svnserve.conf在同級目錄的）。
我們用文本編輯器打開conf目錄中的passwd文件，把我們apache的賬號也加到這裏邊來，這樣我們的賬號不只可以用瀏覽器訪問svn，也可以用tortoiseSVN客戶端來訪問。
這個passwd密碼只能用明文來顯示了，賬號和密碼之間是用=來連接的，這也是區別於apache的passwd文件的兩個地方。關閉該文件，保存。這樣我們就可以用TSVN客戶端訪問了。
2）TSVN客戶端可以把倉庫中的文件checkout到本地，那麼我們現在只是創建了帳戶，如何做權限的限制呢，我們注意到剛纔的conf目錄下，除了svnserve.conf文件和passwd文件，還有另外一個authz文件，沒錯，這個文件就是相當於apache的access文件了，用文本編輯器打開它。它的格式和access如出一轍，我們不做贅述。格式如下：
（注意：由於svn對於中文目錄或者中文名字的文件名敏感，所以我們的access和authz文件格式最好UTF-8 -NO BOM來保存。具體做法是用UltraEdit-32打開它，並將它另存爲UTF-8 -NO BOM格式，以後編輯它的時候可用文本編輯器編輯保存即可。
完成對authz文件的編輯之後，我們來使它生效，打開svnserve.conf文件，找到#authz-db = zuthz這一行，把前面的#號去掉，並且加入一行：
anon = access = none
注：加入的這一行表示匿名訪問的都將沒有任何權限，這一句在本人看來等同與#anon - access=read，但是實驗結果證明，如果沒有加入前者這一句，TSVNcheckout的時候，會提示沒有權限進行編輯。但目前爲止，筆者知其然，而不知其所以然。
補充：
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 的。