Subversion有一個很標準的目錄結構，是這樣的。
比如專案是proj，svn地址為svn://proj/，那麼標準的svn佈局是

svn://proj/
|
+-trunk
+-branches
+-tags

1. 1.0開發完畢，程式碼凍結
2. 基於已經凍結的trunk，為release1.0打tag
   此時的目錄結構為
   svn://proj/
                +trunk/ (freeze)
                +branches/
                +tags/
                        +tag_release_1.0　(copy from trunk)
3. 2.0開始開發，trunk此時為2.0的開發版
4. 發現1.0有bug，需要修改，基於1.0的tag做branch
   此時的目錄結構為
   svn://proj/
                +trunk/ ( dev 2.0 )
                +branches/
                              +dev_1.0_bugfix (copy from tag/release_1.0)
                +tags/
                        +release_1.0　(copy from trunk)
5. 在1.0 bugfix branch進行1.0 bugfix開發，在trunk進行2.0開發
6. 在1.0 bugfix 完成之後，基於dev_1.0_bugfix的branch做release等
7. 根據需要選擇性的把dev_1.0_bugfix這個分支merge回trunk（什麼時候進行這步操作，要根據具體情況）

1. 1.0開發，做dev1.0的branch
   此時的目錄結構
   svn://proj/
                +trunk/ (不擔負開發任務 )
                +branches/
                              +dev_1.0 (copy from trunk)
                +tags/
2. 1.0開發完成，merge dev1.0到trunk
   此時的目錄結構
   svn://proj/
                +trunk/ (merge from branch dev_1.0)
                +branches/
                              +dev_1.0 (開發任務結束，freeze)
                +tags/
3. 根據trunk做1.0的tag
   此時的目錄結構
   svn://proj/
                +trunk/ (merge from branch dev_1.0)
                +branches/
                              +dev_1.0 (開發任務結束，freeze)
                +tags/
                        +tag_release_1.0 (copy from trunk)
4. 1.0開發，做dev2.0分支
   此時的目錄結構
   svn://proj/
                +trunk/ 
                +branches/
                              +dev_1.0 (開發任務結束，freeze)
                              +dev_2.0 （進行2.0開發）
                +tags/
                        +tag_release_1.0 (copy from trunk)
5. 1.0有bug，直接在dev1.0的分支上修復
   此時的目錄結構
   svn://proj/
                +trunk/ 
                +branches/
                              +dev_1.0 (1.0bugfix)
                              +dev_2.0 （進行2.0開發）
                +tags/
                        +tag_release_1.0 (copy from trunk)
6. 選擇性的進行程式碼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.0 merge到dev_2.0，進行測試等之後再merge回trunk。
這兩種方法各有利弊，第一種方法是可以得到一個比較純的dev_2.0的開發分支，而第二種方法則更加的保險，因為要測試嘛。

以上呢，就是我說的兩種開發模式了，具體哪種好，並沒有定論。這裡大致的說一下各自的優缺點
第一種開發模式（trunk進行主要開發，集中式）：
優點：管理簡單
缺點：當開發的模組比較多，開發人數/小團隊比較多的時候，很容易產生衝突而影響對方的開發。因為所有的改動都有可能觸碰對方的改動
第二重開發模式（分支進行主要開發，分散式）：
優點：各自開發獨立，不容易相互影響。
缺點：管理複雜，merge的時候很麻煩，容易死人。