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

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

【編輯推薦】

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