1 SVN標準目錄
Subversion有一個很標準的目錄結構，是這樣的。比如項目是proj，svn地址爲svn://proj/，那麼標準的svn佈局是：
這是一個標準的佈局，trunk爲主開發目錄，branches爲分支開發目錄，tags爲tag存檔目錄（不允許修改）。但是具體這幾個目錄應該如何使用，svn並沒有明確的規範，更多的還是用戶自己的習慣。
trunk：主幹，如果說把一個軟件項目從開始到消亡比作一個故事的話，主線情節都在這裏被SVN記錄着。
branches：分支，有很多種用法，比如：版本發佈維護分支、新特性開發分支，甚至是缺陷修復分支等等。
tags：標籤，或者叫快照，某個版本發佈時候，都在這裏留檔。
示例如圖：
2 集中式：trunk進行主要開發
一般的，我們的所有的開發都是基於trunk進行開發，當一個版本/release開發告一段落（開發、測試、文檔、製作安裝程序、打包等）結束後，代碼處於凍結狀態（人爲規定，可以通過hook來進行管理）。此時應該基於當前凍結的代碼庫，打tag。當下一個版本/階段的開發任務開始，繼續在trunk進行開發。
此時，如果發現了上一個已發行版本（Released Version）有一些bug，或者一些很急迫的功能要求，而正在開發的版本（Developing Version）無法滿足時間要求，這時候就需要在上一個版本上進行修改了。應該基於發行版對應的tag，做相應的分支（branch）進行開發。
例如，剛剛發佈1.0，正在開發2.0，此時要在1.0的基礎上進行bug修正。按照時間的順序：
這是一種很標準的開發模式，很多的公司都是採用這種模式進行開發的。trunk永遠是開發的主要目錄。
3 分散式：分支進行主要開發
這種開發模式當中，trunk是不承擔具體開發任務的，主要承擔版本發佈，一個版本/階段的開發任務在開始的時候，根據已經release的版本做新的開發分支，並且基於這個分支進行開發。還是舉上面的例子，這裏面的時序關係是。
這其實是一種分散式的開發，當各個部分相對獨立一些（功能性的），可以開多個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的開發分支，而第二種方法則更加的保險，因爲要測試嘛。
多人協作時，第六步是最經常出問題的地方，嚴重的甚至會導致代碼被覆蓋回滾情況，其原因在於分支管理者創建分支後不再或長時間從主幹拉回數據，導致最終合併回主幹時分支的文件甚至結構都與主幹有較大差別，產生較多衝突。需要人手解決，浪費了很多時間。
針對這個問題，是否有一種方案可以在分支提交時即檢測該分支最後一次合併的版本是否與主幹版本相符，如果不符則不允許提交，強制要求大家養成從主幹拉數據的習慣呢？如果可以實現，那麼在分支合併回主幹時將幾乎可以消滅掉衝突。
當前解決思路主要有3種：
不間斷強調使用SVN時要經常從主幹同步代碼到分支。該方案缺點很明顯，完全依賴人工，不可信。
在trunk裏單獨維護一個帶最新版本號的readme.md，每次更新trunk時更新該版本到更新的版本號。此後合併分支回主幹時判斷下分支時的readme.md是否和主幹裏的readme.md保持一致，若小於主幹，則強制同步主幹代碼到分支。該方案缺點是需要每次更新主幹代碼時都要強制手工維護版本號，容易出現低級錯誤——更新trunk時忘記更新readme.md裏的版本號等情況。
SVN本身記錄版本更新信息，可以通過在服務器端監控主幹，判斷提交前(pre-commit)檢測是否有分支最後一次合併版本號小於主幹版本號，如果小於則不允許提交，強制要求先從主幹合併。此方案是一種相對完美的方案。
以上呢，就是SVN的兩種開發模式了，具體哪種好，並沒有定論。這裏大致的說一下各自的優缺點：
第一種開發模式（trunk進行主要開發，集中式）：
優點：管理簡單。
缺點：當開發的模塊比較多，開發人數/小團隊比較多的時候，很容易產生衝突而影響對方的開發。因爲所有的改動都有可能觸碰對方的改動。
第二種開發模式（分支進行主要開發，分散式）：
優點：各自開發獨立，不容易相互影響。
缺點：管理複雜，merge的時候很麻煩，容易死人。
4 最後，推薦第一種開發模式
責職說明：
Trunk：用於各版本開發提交代碼
TAG：用於記錄和保存每個release/milestone的代碼
Branch：用於bug fixing
過程說明：
項目開始時，創建Trunk，開始1.0.0開發
所有小組成員都往Trunk中提交代碼
當1.0.0開發完成後，創建一個標籤：Tag1.0.0
Tag1.0.0測試完成後，部署到服務器
開發小組開始新版本1.0.1開發，繼續提交代碼到Trunk中
1.0.1開發完成，創建Tag1.0.1，測試完後部署到服務器
開發小組開始新版本1.0.2開發，繼續提交代碼到Trunk中
1.0.1運行中發現bug，需要緊急修復 -> 從Tag1.0.1中創建1.0.1bug-fix Branch
Bug修復代碼提交到1.0.1bug-fix Branch，測試通過後，部署到服務器
提交到1.0.1bug-fix Branch的代碼合併到Trunk中
And so on……