上節我們介紹了常用SVN目錄結構中針對實例目錄使用的***種方法，本節我們講解一下第二種方法，看完本文你肯定有不少收獲，希望本文能教會你更多東西，歡迎打擊一起來學習SVN目錄結構的使用方法。

第二種方法，在每一個release的branch中進行各自的開發，trunk只做發布使用。
這種開發模式當中，trunk是不承擔具體開發任務的，一個版本/階段的開發任務在開始的時候，根據已經release的版本做新的開發分支，并且基于這個分支進行開發。還是舉上面的例子，這里面的時序關系是。
1.0開發，做dev1.0的branch
此時的SVN目錄結構
svn://proj/
+trunk/(不擔負開發任務)
+branches/
+dev_1.0(copyfromtrunk)
+tags/
1.0開發完成，mergedev1.0到trunk
此時的SVN目錄結構
svn://proj/
+trunk/(mergefrombranchdev_1.0)
+branches/
+dev_1.0(開發任務結束，freeze)
+tags/
根據trunk做1.0的tag
此時的SVN目錄結構
svn://proj/
+trunk/(mergefrombranchdev_1.0)
+branches/
+dev_1.0(開發任務結束，freeze)
+tags/
+tag_release_1.0(copyfromtrunk)
1.0開發，做dev2.0分支
此時的目錄結構
svn://proj/
+trunk/
+branches/
+dev_1.0(開發任務結束，freeze)
+dev_2.0（進行2.0開發）
+tags/
+tag_release_1.0(copyfromtrunk)
1.0有bug，直接在dev1.0的分支上修復
此時的SVN目錄結構
svn://proj/
+trunk/
+branches/
+dev_1.0(1.0bugfix)
+dev_2.0（進行2.0開發）
+tags/
+tag_release_1.0(copyfromtrunk)
選擇性的進行代碼merge
這其實是一種分散式的開發，當各個部分相對獨立一些（功能性的），可以開多個dev的分支進行開發，這樣各人/組都不會相互影響。比如dev_2.0_search和dev_2.0_cache等。但是這樣merge起來就是一個很痛苦的事情。
這里要注意一下的，第六步進行選擇性的merge，是可以當2.0開發結束后一起把dev_1.0（bugfix用）和dev_2.0（新版本開發用）merge回trunk。或者先把dev_1.0merge到dev_2.0，進行測試等之后再merge回trunk。
這兩種方法各有利弊，***種方法是可以得到一個比較純的dev_2.0的開發分支，而第二種方法則更加的保險，因為要測試嘛。
以上呢，就是我說的兩種開發模式了，具體哪種好，并沒有定論。這里大致的說一下各自的優缺點：
***種SVN目錄結構開發模式（trunk進行主要開發，集中式）：
優點：管理簡單
缺點：當開發的模塊比較多，開發人數/小團隊比較多的時候，很容易產生沖突而影響對方的開發。因為所有的改動都有可能觸碰對方的改動
第二種SVN目錄結構開發模式（分支進行主要開發，分散式）：
優點：各自開發獨立，不容易相互影響。
缺點：管理復雜，merge的時候很麻煩，容易死人。
其實，這里并沒有一定之規，更多的時候是兩種模式結合使用。我個人來說是采用***種方式為主，在某些情況下使用第二種方法。本節關于SVN目錄結構的使用方法講解完畢，請關注本節其他相關報道。
 

【編輯推薦】

1. 常用SVN目錄結構簡明介紹
2. SVN庫的目錄結構詳解
3. ApacheSVN服務器安裝指導手冊
4. 兩種常見SVN庫結構簡明介紹
5. SVN服務器安裝指導手冊