1.0開發，做dev1.0的branch
此時的目錄結構
svn://proj/
+trunk/ (不負擔開發任務)
+branches/
+dev_1.0 (copy from trunk)
+tags/
1.0開發完成，merge dev1.0到trunk
此時的目錄結構
svn://proj/
+trunk/ (merge from branch dev_1.0) ===>測試，打tag或者修改合併後的bug，擔負bug程式碼修改
+branches/
+dev_1.0 (開發任務結束，freeze)
+tags/
1) 合併後，測試如果有bug，可以直接在trunk上修改bug，直到修正後打tag進行釋出
2）合併後，測試無問題直接打tag釋出
釋出後發現存在bug：需要修改，基於1.0的tag做branch_buffix_1.0
此時的目錄結構
svn://proj/
+trunk/
+branches/
+dev_1.0 (開發任務結束，freeze)
+dev_2.0 （進行2.0開發）
+branch_buffix_1.0
+tags/
+tag_release_1.0 (copy from trunk)
1）如果2.0開發開始，但並沒合併入主幹：branch_buffix_1.0中修正bug後合併到主幹，通過主幹打tag釋出
2）如果2.0開發結束，而且合併入主幹：branch_buffix_1.0中修正bug後依然合併到主幹，但通過分支branch_buffix_1.0打tag釋出
依次類推！！
總結：
1）tag上不做任務程式碼修改
2）新需求開發，從主幹（最新穩定的）做分支在分支上開發
3）新需求分支開發完成或者分支bug修正後，都必須合併到主幹
4）主幹可在合併後發現問題（並沒打tag）做部分修改
這是方法之一，比較適用於那些經常改動，bug較多的網站開發。