subversion有乙個很標準的目錄結構，是這樣的。比如專案是proj，svn位址為svn://proj/，那麼標準的svn布局是
svn://proj/
|+-trunk
+-branches
+-tags
這 是乙個標準的布局，trunk為主開發目錄，branches為分支開發目錄，tags為tag存檔目錄（不允許修改）。但是具體這幾個目錄應該如何使 用，svn並沒有明確的規範，更多的還是使用者自己的習慣。
對於這幾個開發目錄，一般的使用方法有兩種。我更多的是從軟體產品的角度出發 （比如freebsd），因為網際網路的開發模式是完全不一樣的。
第一種方法，使用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永遠是開發的主要目錄。
第二種方法，在每乙個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的分支上修復
此時的目錄結構
svn://proj/
+trunk/
+branches/
+dev_1.0 (1.0bugfix)
+dev_2.0 （進行2.0開發）
+tags/
+tag_release_1.0 (copy from trunk)
選擇性的進行**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的時候很麻煩，容易死人。
其實，這裡並沒有一定之規，更多的時候是兩種 模式結合使用。
SVN常用目錄結構
svn常用目錄結構 特殊目錄名說明 trunk 主幹,儲存最新穩定版本 tag 標記,主要儲存比較完整理的版本標記,類似里程碑 tranch 分支,用於分工操作.該目錄下又以各使用者名稱及日期為目錄進行儲存 推薦 關於目錄 結構舉例,相對規範 doc 文件的 根目錄 doc trunk 文件的 版本...
SVN 專案的目錄結構
svn 專案的目錄結構 乙個 svn 專案的良好目錄結構如下 project1 trunk branches tags 1.project1 專案名。2.trunk 主幹目錄，用於主幹產品的維護。大部分操作都在此目錄下完成。3.branches 分支目錄，用於分支產品的維護。分支目錄通過 trunk...
svn目錄結構組成的教程
svn目錄結構組成的教程 wolfwebadmin projectmanagement trunk branches tags sso trunk branches tags 大概的說一下,projectmanagement和sso是兩個專案 trunk是開發的主線 存放能夠執行的正確的 程式設計師...