代碼管理實踐
代碼倉庫均採用subversion來管理，
-
代碼目錄的創建，
一般創建三個目錄分別爲
trunk(主幹)，
tags（標籤/標記)，只存儲快照。
branches(分支)。
tags和branches下一般爲根據需要從trunk目錄拷貝過來的。
-
tags（基線）的創建要求。
-
代碼在一種平臺下通過編譯（必須）
-
代碼編譯出來的版本通過一定的冒煙測試。
-
在項目要求的平臺都可以編譯通過。
-
一般有一個安裝包給測試時，就需要在tags下建立對應代碼的標籤。
-
tags下的代碼一般不可以修改。
-
兩種代碼管理模式介紹:
-
始終分支系統(OpenOffice社區採用管理方式)
典型特徵:項目較大，代碼較多，編譯時間較長，參與人員比較多時。
-
每個用戶對每項 編碼任務的創建或操作都是在私有分支（cws）中進行的。
-
編碼完成後，原編碼者、同級或經理將對所有私有分支的更改進行審查並將它由合併到 /trunk 中。
-
里程碑(基線)的創建
集成人員集成將開發人員提交的功能集成到主幹上，編譯通過後，提交的主幹上，集成了一定的功能後，創建一個里程碑版本，一般建議按周創建里程碑版本。並在tags下創建相應的代碼快照，並將安裝包傳至指定位置。
-
開發人員基於里程碑版本開發。
開發人員一般基於最新的里程碑版本創建分支，並在分支上工作，並在自己的分支上提交，在提交到svn之前需要編譯通過。開發人員需要根據自己開發情況來同步到主幹的里程碑代碼。如果需要集成到主幹上，需要同步到最近的里程碑。
-
測試人員.
測試人員對開發人員的代碼進行測試，達到一定的測試標準後，測試通過，然後交由集成人員來集成。
-
-
按需分支系統（Subversion社區採用管理方式）
適用方式代碼較少，或者參與開發的人員較少
-
開發人員可以直接在主幹上提交。開發負責人來編譯版本給測試。
-
開發者把所有的新特性提交到主幹。 每日的修改提交到/trunk：新特性，bug修正和其他。新近的開發人員不能提交代碼，交由有經驗的開發人員驗證後來提交到主幹上。
-
當開發小組認爲軟件已經做好基本發佈的準備(如，版本1.0)然後/trunk會被拷貝到/branches/1.0。這個主幹被拷貝到“發佈”分支。然後在發佈分支上繼續修改bug.
-
如果bug修正經測試達到一定的要求認爲可以完成時，可以拷貝到/tags/1.0.0，這個標籤被建立併發布給相關人員。
-
-
向subversion庫提交提交代碼要求
-
針對每次提交到主幹上的代碼均需要編譯通過
-
代碼每次提交到svn上均需要添加註釋。
-
每個人都用自己賬號來提交代碼。
-
參考資料
http://www.subversion.org.cn/svnbook/nightly/
http://wiki.services.openoffice.org/wiki/OOo_and_Subversion
http://www.collab.net/scdocs/SVNTips.html
http://bjbook.net/bk/scmbest/