版本控制規范
1. 簡介
1.1 目的
版本控制規范用於確定軟件配置項的命名與版本號管理的規則，以確保清楚地、唯一地標識軟件的各個組成部分及其狀態，並建立這些部分之間的一致性關系。
1.2 范圍
版本控制的范圍包括：
² 源代碼：用計算機編程語言編寫的源代碼文件
² 文檔：需求文檔、架構設計文檔、數據庫設計文檔等描述軟件功能和結構的技術文檔；項目計划等項目管理文檔以及各種測試文檔和用戶文檔
² 產品包：將源代碼進行編譯得到的可運行的軟件系統
2. 產品標識
在每個軟件產品立項時建立該軟件產品的標識，以唯一地代表一個軟件產品或項目，產品標識也稱為項目標識。
2.1 產品名稱
新產品立項時，為產品賦予產品名稱；當已有產品升級時，則沿用前一版本產品的名稱。
產品名稱包括：
² 產品中文名稱：如：制造執行系統，倉庫管理系統等等
² 產品英文名稱：如：Manufacturing Execution Systems，Warehouse Management System
² 產品英文簡稱：如：MES，WMS
產品名稱用於相關文檔的編寫和產品的發布。
產品名稱不是某一產品的唯一標識，必須與版本號一起用才能標識特定產品。
2.2 版本號
版本號用來標識開發、測試、交付階段的不同狀態的產品，版本號格式為：
<主版本號>.<次版本號>.<小版本號>-[Build號]
² 主版本號：立項時設置，在整個項目開發過程中不改變
² 次版本號：立項時設置，在整個項目開發過程中不改變
² 小版本號：立項時設置，在整個項目開發過程中不改變
² Release號：又叫Build號，內部測試開始之前設置，初始值為0，此后每產生一次小的修改，Release號+1
版本號的一般形式如：1.0.7-101，2.0.0-900
3. 版本規范
3.1 版本號設置規則
3.1.1 主版本號
1、 設置時間：產品立項時設置
2、 設置規則：
² 新產品立項，主版本號為1
² 產品構架發生改變，主版本號+1
² 產品主要組件（比如訂單處理框架）進行重大修改，主版本號+1
² 產品對外接口協議發生更改，主版本號+1
3.1.2 次版本號
1、 設置時間：產品立項時設置
2、 設置規則：
² 新產品立項，次版本號為0
² 為處理產品Bug或改進現有功能/性能，對現有功能模塊做大的修改，但不增加新的功能模塊，副版本號+1
² 為增加產品功能，在原版本產品上增加新的功能模塊，而產品的主體構件未做重大修改，並且產品的主體構件之間的接口協議也未做修改，副版本號+1
² 為適應不同用戶需求，對產品進行更改，而產品的主體構件未做重大修改，並且產品的主體構件之間的接口協議也未做修改，副版本號+1
² 當主版本號變更時，副版本號同時置0
3.1.3 小版本號
² 新產品立項，小版本號為0
² 修復Bug或改進現有功能，但不對現有功能模塊做大的修改，不增加新的功能模塊，小版本號+1
² 當次版本號變更時，小版本號同時置0
3.1.4 Build號
1、 設置時間：產品開發結束，內部測試開始之前
2、 設置規則：
² Release號初始值為0
² 測試過程中，每進行一次修改，Release號+1
3.2 版本管理
3.2.1 trunk
任何時候trunk里包含的都是最新的開發代碼。 這里的代碼將會工作到下一個主要發布版本。
trunk應該只被用來開發將會成為你的下一個重要版本的代碼。 不要給trunk加上版本號和發布名稱。 僅需要保證trunk在任何時候都處於“開發模式”。
3.2.2 branches
有幾種不同類型的分支。在branches的目錄里，可以為更多具體的目標創建路徑，像即將發行版本。Brahches可以包含了trunk在不同發展階段的副本。
3.2.2.1 Release Branches
當trunk達到准備發布的階段時（或者你想凍結新特色的添加時），應該創建一個release branches。 Release branches只是當前trunk的一個副本。
這個branches可以被單獨的簽出，也可以啟動branches和基於此版本的項目。還可以使用此分支在測試期間修復Bug。 這種方式能夠保證trunk繼續開發，而不會被發布某個具體的版本所干擾。 因此當准備發布一個新版本時，不會影響trunk增加新的功能。
3.2.2.2 Bug fix branches
分支也可以用於處理trunk或release branches里發現的嚴重的Bug。這些Bug很復雜，不能在一次提交時就修復他們。因此為了集中精力修正此錯誤，應該為此問題創建一個新的分支。這樣就不會影響trunk 和 release branches的繼續進行，並且也不會因為發現新的Bug 和測試而干擾此Bug 的修復。
3.2.2.3 Experimental branches
有時想將某個新技術引進項目。但是不想影響到整個項目。比如想把web應用從spring3x改為spring4x。要花多少時間？在這期間trunk停止使用？直到把所有到spring的轉換做完。
可能Spring4x對程序變動較大，應該創建一個實驗分支。 這樣就可以在分支里進行更改，如果失敗了，不影響當前應用，實驗分支可以拋棄。 如果成功，可以很容易的將其合並到trunk。
3.2.3 tags
tags用來備份代碼，通常是readonly的，不被用來開發，只是用來標記代碼的狀態。
3.2.3.1 1.3.1 Release tags
Release Tags 標記版本發布點的代碼。 Release Tag 永遠是相應發布分支的副本。 Release Tag命名規則：版本號+“Release”后綴。
4. SVN使用規范
4.1 先更新，再提交
SVN更新的原則是要隨時更新，隨時提交。當完成了一個小功能，能夠通過編譯並且自己測試之后，謹慎地提交。
如果在修改的期間別人也更改了svn的對應文件，那么commit就可能會失敗。如果別人和自己更改的是同一個文件，那么update時會自動進行合並，如果修改的是同一行，那么合並時會產生沖突，這種情況就需要同之前的開發人員聯系，兩個人一起協商解決沖突，解決沖突之后，需要兩人一起測試保證解決沖突之后，程序不會影響其他功能。
在更新時注意所更新文件的列表，如果提交過程中產生了更新，則也是需要重新編譯並且完成自己的一些必要測試，再進行提交。這樣既能了解別人修改了哪些文件，同時也能避免SVN合並錯誤導致代碼有錯。
4.2 多提交
每次提交的間歇盡可能地短，以幾個小時的開發工作為宜。例如在更改UI界面的時候，可以每完成一個UI界面的修改或者設計，就提交一次。在開發功能模塊的時候，可以每完成一個小細節功能的測試，就提交一次，在修改bug的時候，每修改掉一個bug並且確認修改了這個bug，也就提交一次。提倡多提交，也就能多為代碼添加上保險。
4.3 不要提交不能通過編譯的代碼
代碼在提交之前，首先要確保能夠在本地編譯。項目經理在准備項目工作區域的時候，需要確保開發小組成員在簽出代碼之后能夠在統一的環境中進行編譯。
4.4 每次提交必須書寫明晰的標注
在一個項目組中使用SVN，如果提交空的標注或者不確切的標注將會讓項目組中其他的成員感到很無奈，項目經理無法很清晰的掌握工作進度，無法清晰的把握此次提交的概要信息。在發現錯誤后也無法准確的定位引起錯誤的文件。所以，在提交工作時，要填寫明晰的標注，能夠概要的描述所提交文件的信息，讓項目組其他成員在看到標注后不用詳細看代碼就能了解你所做的修改。
4.5 提交時注意不要提交本地自動生成的文件
例如eclipse中的.classpath文件，Windows生成的縮略圖Thumbs.db，項目編譯生成的臨時文件.obj, .class等等。如果項目中沒有進行這方面的配置來強行禁止提交這樣的文件，請自覺不要提交這樣的文件。提交了這樣的文件后，別人在更新后就可能與本地的環境沖突從而影響大家的工作。
4.6 不要提交自己不明白的代碼
代碼在提交入SVN之后，你的代碼將被項目成員所分享。如果提交了你不明白的代碼，你看不懂，別人也看不懂，如果在以后出現了問題將會成為項目質量的隱患。因此在引入任何第三方代碼之前，確保你對這個代碼有一個很清晰的了解。
4.7 慎用鎖定功能
在項目中要慎用鎖定的功能，在你鎖定了一個文件之后別人就無法繼續修改提交該文件，雖然可以減少沖突的發生率，但是可能會影響項目組中其他人員的工作。平時只有在編輯那些無法合並的文件（例如圖片文件，flash文件等）時，才適當的采用鎖定操作。
5. 目錄結構
