使用SVN進行項目版本管理
1.摘要
本文描述了利用SVN進行項目版本管理的方法，涉及項目版本號命名規則、SVN目錄結構、第三方代碼庫的管理、版本創建、發佈、修訂、合併等行爲的方法和原則。
2.版本號命名規則
版本號採用主版本號.次版本號.修訂號組成。版本的重大變化主版本號增1，次版本號和修訂號歸零。版本的相對較小的變化主版本號維持不變，次版本號增1，修訂號歸零。當一個版本發佈後出現了bug需要修訂，此時，主、次版本號不變，修訂號增1。
注意：對於主動性的程序功能性的變化，應該增加主或次版本號，不應該通過修訂號來反映。修訂號只用於對已發佈版本的bug修訂，一個版本的修訂號的大小某種程度上可以反映一個版本發佈後的穩定情況。
3.SVN目錄結構
項目結構
第三方庫結構
以項目名稱作爲SVN倉庫名稱爲項目創建獨立的項目倉庫。倉庫主要結構分爲branches和tags。branches爲工作目錄，tags爲發佈目錄。項目使用到的第三方庫獨立出來單獨組件項目倉庫，爲整個公司的所有項目所共享，倉庫名稱爲vendor。
3.1項目結構
branches
分支，存放未發佈版本。具體的某個版本存放在其下的一個以“RB-版本號”規則命名的文件夾。上圖示例爲當前存在兩個正在開發的版本RB-2.0和RB3.0。分支是開發人員的工作目錄，是版本實現過程中的中間成果，具有臨時性。版本發佈後，相應的分支即可銷燬。
tags
標籤，存放已發佈版本。具體的某個版本存放在其下的一個以“REL-版本號”規則命名的文件夾。上圖示例爲當前存在兩個已發佈版本REL-1.0和REL-1.1。該目錄只讀，即不允許對任何已發佈版本做任何修改。
版本內部結構
doc：文檔存放目錄
src：源碼存放目錄
bin：可執行文件、動態庫、腳本、配置文件等發佈項及pdb、mapfile、obj存放目錄。
vendor
存放第三方庫的變更記錄文件change.xls。由於第三方庫不常變動且庫大，若與項目代碼存放在一起，則簽出代碼量會過大，耗時長。因此項目內部僅存放一個變更記錄文件。倘若出現第三庫存在變更，例如，某項目從3.0開始，xerces庫升級到2.8，則在change.xls文件中登記即可，change.xls結構如下表所示。
|
庫名 |
庫版本 |
項目版本 |
變更日期 |
備註 |
|
ace |
4.5 |
1.0 |
2010-1-1 |
|
|
boost |
1.39 |
1.0 |
2010-1-1 |
|
|
xerces |
2.6 |
1.0 |
2010-1-1 |
|
|
xerces |
2.8 |
3.0 |
2011-12-29 |
|
上表第4行表示在項目3.0時，xerces庫從2.6升級到了2.8。
3.2第三方庫結構
第三方庫單獨成立SVN倉庫，位置級別上升爲與各項目平級，爲公司內各項目所共享，其結構見上圖。
4.常見操作
4.1新建版本
當確定需要建立一個版本時，則需要在branches下創建一個相應的版本分支，用於版本實現過程中的配置項管理。分支的創建可以從頭創建也可以基於tags中的已發佈版本創建。例如，要在REL-1.1的基礎上開發2.0，則從tags\REL-1.1創建一個RB-2.0。
4.2日常工作
項目經理在給開發人員分派任務時必須制定版本號，即任務所屬版本。開發人員根據任務的版本號屬性在相應的工作分支中實現和提交工作成果物。這樣，開發人員只需要知道任務所屬版本號，無需關心版本之間的關係。項目經理需要對版本及其之間的關係有清晰的認識和規劃。
4.3版本發佈
當一個版本進入待發布狀態後，需要爲版本創建發佈標籤，即從版本分支創建一個版本標籤。如2.0，則從branches\RB-2.0創建一個tags\REL-2.0。版本發佈人員必須從tags下取發佈項進行發佈，杜絕發佈人員從分支或者其他地方獲取發佈項進行發佈。
4.4版本修訂
當一個已發佈版本出現bug需要修訂時，需要從相應的已發佈版本中創建一個分支版本。例如2.0發佈後出現bug，則從tags\REL-2.0創建一個branches\RB-2.0.1。注意，修訂號必須增加，版本不能回退也不能原地變化，即不管是新功能還是bug修訂，只要是變更，版本號必增。帶修訂版本進入待發布狀態後，則進入版本發佈流程。
4.5版本合併
當多個版本處於並行工作狀態下，例如RB-1.0.1（修復1.0發佈後的bug）和RB-1.1(1.0發佈後，在此基礎上增加的新功能)兩個版本並行工作，RB-1.0.1先於RB-1.1完成併發布， 那麼RB-1.0.1發佈後會創建REL-1.0.1，需要將REL-1.0.1的修改合併到RB-1.1，否則會出現1.0.1修改過的bug在新版本1.1中又重新出現了。