原文地址：https://www.cnblogs.com/dafozhang/archive/2012/06/28/2567769.html
Subversion有一個很標準的目錄結構，是這樣的。
比如專案是proj，svn地址為svn://proj/，那麼標準的svn佈局是
svn://proj/|+-trunk+-branches+-tags
這是一個標準的佈局，trunk為主開發目錄，branches為分支開發目錄，tags為tag存檔目錄（不允許修改）。但是具體這幾個目錄應該如何使用，svn並沒有明確的規範，更多的還是使用者自己的習慣。
對於這幾個開發目錄，一般的使用方法有兩種。我更多的是從軟體產品的角度出發（比如freebsd），因為網際網路的開發模式是完全不一樣的。 1.第一種方法，使用trunk作為主要的開發目錄
一般的，我們的所有的開發都是基於trunk進行開發，當一個版本/release開發告一段落（開發、測試、文件、製作安裝程式、打包等）結束後，程式碼處於凍結狀態（人為規定，可以通過hook來進行管理）。此時應該基於當前凍結的程式碼庫，打tag。當下一個版本/階段的開發任務開始，繼續在trunk進行開發。
此時，如果發現了上一個已發行版本（Released Version）有一些bug，或者一些很急迫的功能要求，而正在開發的版本（Developing Version）無法滿足時間要求，這時候就需要在上一個版本上進行修改了。應該基於發行版對應的tag，做相應的分支（branch）進行開發。
例如，剛剛釋出1.0，正在開發2.0，此時要在1.0的基礎上進行bug修正。
按照時間的順序
1.0開發完畢，程式碼凍結
基於已經凍結的trunk，為release1.0打tag
此時的目錄結構為
svn://proj/
+trunk/ (freeze)
+branches/
+tags/
+tag_release_1.0 (copy from trunk)
2.0開始開發，trunk此時為2.0的開發版
發現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)
在1.0 bugfix branch進行1.0 bugfix開發，在trunk進行2.0開發
在1.0 bugfix 完成之後，基於dev_1.0_bugfix的branch做release等
根據需要選擇性的把dev_1.0_bugfix這個分支merge回trunk（什麼時候進行這步操作，要根據具體情況）
這是一種很標準的開發模式，很多的公司都是採用這種模式進行開發的。trunk永遠是開發的主要目錄。
2.第二種方法，在每一個release的branch中進行各自的開發，trunk只做釋出使用。
這種開發模式當中，trunk是不承擔具體開發任務的，一個版本/階段的開發任務在開始的時候，根據已經release的版本做新的開發分支，並且基於這個分支進行開發。還是舉上面的例子，這裡面的時序關係是：
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)
+branches/
+dev_1.0 (開發任務結束，freeze)
+tags/
根據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)
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)
1.0有bug，直接在dev1.0的分支上修復