|
Subversion有一個很標準的目錄結(jié)構(gòu),，是這樣的,。比如項目是proj,，svn地址為svn://proj/，那么標準的svn布局是
svn://proj/
|
+-trunk
+-branches
+-tags
這 是一個標準的布局,，trunk為主開發(fā)目錄,，branches為分支開發(fā)目錄，tags為tag存檔目錄（不允許修改）,。但是具體這幾個目錄應該如何使 用,，svn并沒有明確的規(guī)范，更多的還是用戶自己的習慣,。
對于這幾個開發(fā)目錄,，一般的使用方法有兩種。我更多的是從軟件產(chǎn)品的角度出發(fā) （比如freebsd）,，因為互聯(lián)網(wǎng)的開發(fā)模式是完全不一樣的,。
第一種方法，使用trunk作為主要的開發(fā)目錄,。
一般的，我們的所有的開 發(fā)都是基于trunk進行開發(fā),，當一個版本/release開發(fā)告一段落（開發(fā),、測試,、文檔、制作安裝程序,、打包等）結(jié)束后,，代碼 處于凍結(jié)狀態(tài)（人為規(guī)定，可以通過hook來進行管理）,。此時應該基于當前凍結(jié)的代碼庫,，打tag。當下一個版本/階段的開發(fā)任務開始,，繼續(xù)在trunk 進行開發(fā),。此時，如果發(fā)現(xiàn)了上一個已發(fā)行版本（Released Version）有一些bug,，或者一些很急迫的功能要求,，而正在開發(fā)的版本（Developing Version）無法滿足時間要求，這時候就需要在上一個版本上進行修改了,。應該基于發(fā)行版對應的tag,，做相應的分支（branch）進行開發(fā)。例 如,，剛剛發(fā)布1.0,，正在開發(fā)2.0，此時要在1.0的基礎上進行bug修正,。
按照時間的順序
- 1.0開發(fā)完畢,，代碼 凍結(jié)
- 基于已經(jīng)凍結(jié)的trunk，為release1.0打tag
此時的目錄結(jié)構(gòu)為
svn://proj/
+trunk/ (freeze)
+branches/
+tags/
+tag_release_1.0 (copy from trunk)
- 2.0 開始開發(fā),，trunk此時為2.0的開發(fā)版
- 發(fā)現(xiàn)1.0有bug,，需要修改，基于1.0的tag做branch
此時的目錄結(jié)構(gòu) 為
svn://proj/
+trunk/ ( dev 2.0 )
+branches/
+dev_1.0_bugfix (copy from tag/release_1.0)
+tags/
+release_1.0 (copy from trunk)
- 在1.0 bugfix branch進行1.0 bugfix開發(fā),，在trunk進行2.0開發(fā)
- 在1.0 bugfix 完成之后,，基于dev_1.0_bugfix的branch做release等
- 根據(jù)需要選擇性的把 dev_1.0_bugfix這個分支merge回trunk（什么時候進行這步操作，要根據(jù)具體情況）
這是一種很標準的開發(fā)模 式,，很多的公司都是采用這種模式進行開發(fā)的,。trunk永遠是開發(fā)的主要目錄。
第二種方法,，在每一個release的branch中進行 各自的開發(fā),，trunk只做發(fā)布使用。這種開發(fā)模式當中,，trunk是不承擔具體開發(fā)任務的,，一個版本/階段的開發(fā)任務在開始的時候，根據(jù)已經(jīng) release的版本做新的開發(fā)分支,，并且基于這個分支進行開發(fā),。還是舉上面的例子,，這里面的時序關(guān)系是。
- 1.0開發(fā),，做 dev1.0的branch
此時的目錄結(jié)構(gòu)
svn://proj/
+trunk/ (不擔負開發(fā)任務 )
+branches/
+dev_1.0 (copy from trunk)
+tags/
- 1.0開發(fā)完成,，merge dev1.0到trunk
此時的目 錄結(jié)構(gòu)
svn://proj/
+trunk/ (merge from branch dev_1.0)
+branches/
+dev_1.0 (開發(fā)任務結(jié)束，freeze)
+tags/
- 根據(jù)trunk做1.0的tag
此時的目錄結(jié)構(gòu)
svn://proj/
+trunk/ (merge from branch dev_1.0)
+branches/
+dev_1.0 (開發(fā)任務結(jié)束,，freeze)
+tags/
+tag_release_1.0 (copy from trunk)
- 1.0開發(fā),，做dev2.0分支
此時的目錄結(jié)構(gòu)
svn://proj/
+trunk/
+branches/
+dev_1.0 (開發(fā)任務結(jié)束，freeze)
+dev_2.0 （進行2.0開發(fā)）
+tags/
+tag_release_1.0 (copy from trunk)
- 1.0有bug,，直接在dev1.0的分支上修復
此時的目錄結(jié)構(gòu)
svn://proj/
+trunk/
+branches/
+dev_1.0 (1.0bugfix)
+dev_2.0 （進行2.0開發(fā)）
+tags/
+tag_release_1.0 (copy from trunk)
- 選擇性的進行代碼merge
這其實是一種分散式的開發(fā),，當各個部分相對 獨立一些（功能性的），可以開多個dev的分支進行開發(fā),，這樣各人/組都不會相互影響,。比如dev_2.0_search和dev_2.0_cache 等。但是這樣merge起來就是一個很痛苦的事情,。
這里要注意一下的,，第六步進行選擇性的merge，是可以當2.0開發(fā)結(jié)束后一起把 dev_1.0（bugfix用）和dev_2.0（新版本開發(fā) 用）merge回trunk,?；蛘呦劝裠ev_1.0 merge到dev_2.0，進行測試等之后再merge回trunk,。
這兩種方法各有利弊,，第一種方法是可以得到一個比較純的dev_2.0的 開發(fā)分支，而第二種方法則更加的保險,，因為要測試嘛,。
以上呢，就是我說的兩種開發(fā)模式了,，具體哪種好,，并沒有定論。這里大致的說一下各自 的優(yōu)缺點
第一種開發(fā)模式（trunk進行主要開發(fā),，集中式）：
優(yōu)點：管理簡單
缺點：當開發(fā)的模塊比較多,，開發(fā)人數(shù)/小團隊比較多 的時候，很容易產(chǎn)生沖突而影響對方的開發(fā),。因為所有的改動都有可能觸碰對方的改動
第二重開發(fā)模式（分支進行主要開發(fā),，分散式）：
優(yōu)點：各 自開發(fā)獨立，不容易相互影響,。
缺點：管理復雜,，merge的時候很麻煩，容易死人,。
其實,，這里并沒有一定之規(guī),，更多的時候是兩種 模式結(jié)合使用,。
|
