Subversion有一個很標准的目錄結構，是這樣的。比如項目是proj，svn地址為svn://proj/，那么標准的svn布局是
svn://proj/
|
+-trunk
+-branches
+-tags
所有的開 發都是基於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永遠是開發的主要目錄。