一、背景

        雖然現在很多公司都使用Git作為版本控制工具使用，但是svn仍然在很多公司中被廣泛使用，尤其在一些規模不大的公司中使用得更廣。

二、SVN

        SVN的全稱是subversion，是一個開源的版本控制系統。對一般的使用者而言，SVN本身沒有太多的技術含量。但是，作為一個軟體而言，還是有很多的技巧值得好好研究的。本文的目的不在於如何“高技巧”的使用svn，而是如何規範的使用svn，進而提高我們的程式碼質量，減少人力成本。當然，本文的目的純粹是作為自己的應用筆記，方便自己日後好查閱相關的知識。文中的錯誤以及不當之處必然存在，歡迎大家指正，感激不盡！

三、規範化提交程式碼

     3.1、svn日誌描述

        在我們的程式碼完成一個任務並且測試沒有問題之後，應該儘快將程式碼提交到svn版本庫中，而在提交的時候svn工具會提示我們輸入日誌。日誌當然可以隨便輸入，但是我們要說的是如何規範日誌的寫法。這一點很重要，因為日後的開發過程中不免要回頭看看上一個版本中我們修改了哪些內容。也許前面一兩個版本的內容開發人員會記得比較清楚，但是再往前便不一定了。所以，在每次上傳程式碼到svn版本庫的時候一定要詳細的記錄本次修改了哪些內容，這就體現在日誌如何填寫了。根據我個人的總結，以及參考其他人的寫法，得到了一個簡介的日誌模板： /*****************************************************************Start：SVN日誌模板*****************************************************************************/ 【提交型別】： Bug修復/階段性提交/追加遞交/新功能/需求修改/解決編譯不過/程式碼整理/初次提交
【問題描述】：                               1、添加了xxx功能；                              2、解決了xxx導致的xxx問題；                              ...... 【修改內容】：                               1、xxx.h檔案中新增/修改了xxx；                              2、xxx.hc檔案中新增/修改了xxx；                              ......
【相關單號】： Bug號/庫版本號/......
【評  審  人】： xxx
【需要測試】： 是/否
/*****************************************************************End：SVN日誌模板******************************************************************************/
舉個例子，假如說本次程式碼時第一次上傳svn，那我們在填寫日誌時可以這樣填寫： 【提交型別】： 初次提交
【問題描述】： 初次提交DIL模組程式碼
【修改內容】： 所有程式碼均為初次提交
【相關單號】： DIL庫版本號1.00.000
【評  審  人】： 張三
【需要測試】： 否

     3.2、svn日誌模板化

        svn工具提供了方便的日誌模板管理，我們可以在使用之前將模板加入svn的屬性中，然後填入模板，這樣每次提交程式碼的時候便不用手動輸入模板，而且不容易產生手動輸入的錯誤。以TortoiseSVN為例，此操作的步驟如下。         （1）、在本地svn目錄下，右鍵選擇TortoiseSVN->Properties，如下圖所示：
        （2）、在彈出的視窗中，點選New，選擇Other，如下圖所示：

        （3）、在彈出的視窗中，點選下拉款，選擇tsvn:logtemplate，在Property value視窗中填入模板即可。如下圖所示：

四、規範化使用svn版本庫目錄：

        svn目錄建立以後，一般會產生三個目錄：branches、tags、trunk。一般表示的意思為trunk為主開發目錄，branches表示分支開發目錄，tags表示存檔目錄（tags目錄不允許修改）。正常情況下，沒有明文規定這三個目錄應該怎麼使用。但是，業界也有個隱含的規範，很多大公司也是按照這個規範來進行專案開發。如下：         （1）、正常情況下，都在trunk目錄下開發。比如，開發某個專案的1.0版本；         （2）、1.0版本的程式碼已經完成，且測試通過，可以正式對外發布release版本。這時候就應該將現在處於trunk目錄下的版本打個標籤到tags目錄下面進行存檔；         （3）、開始開發2.0版本，在trunk目錄下開發；           （4）、此時，發現1.0版本的程式碼中存在某個Bug。此時需要修改1.0的版本，將tags目錄下的1.0版本branch到branches目錄下進行Bug修復；             （5）、1.0版本的Bug已經修復，且測試通過，可以釋出1.0_bugfix的release版本。此時可以根據需要選擇性的將1.0_bugfix版本merge回trunk；

五、參考文獻：