有一些標準的，推薦的組織版本庫的方式，許多人建立一個trunk目錄來保存開發的「主線」，一個branches目錄存放分支拷貝，一個tags目錄保存標籤拷貝，如果一個版本庫只是存放一個項目，人們會在最上層目錄建立這些目錄：

/trunk
/branches
/tags

如果一個版本庫保存了多個項目，管理員會通過項目來部署(見「規劃你的版本庫結構」一節關於「項目根目錄」)：

/paint/trunk
/paint/branches
/paint/tags
/calc/trunk
/calc/branches
/calc/tags

當然，你可以自由的忽略這些通常的部署方式，你可以建立任意的變化，只要是對你和你的項目有益，記住無論你選擇什麼，這不會是一種永久的承諾，你可以隨時重新組織你的版本庫。因為分支和標籤都是普通的目錄，svn move命令可以任意的改名和移動它們，從一種部署到另一種大概只是一系列伺服器端的移動，如果你不喜歡版本庫的組織方式，你可以任意修改目錄結構。

記住，儘管移動目錄非常容易，你必須體諒你的用戶，你的修改會讓你的用戶感到迷惑，如果一個用戶的擁有一個版本庫目錄的工作副本，你的svn move命令也許會刪除最新的版本的這個路徑，當用戶運行svn update，會被告知這個工作副本引用的路徑已經不再存在，用戶需要強制使用svn switch轉到新的位置。

另一個Subversion模型的可愛特性是分支和標籤可以有有限的生命週期，就像其它的版本化的項目，舉個例子，假定你最終完成了calc項目你的個人分支上的所有工作，在合併了你的所有修改到/calc/trunk後，沒有必要繼續保留你的私有分支目錄：

$ svn delete http://svn.example.com/repos/calc/branches/my-calc-branch \
             -m "Removing obsolete branch of calc project."

Committed revision 375.

你的分支已經消失了，當然不是真的消失了：這個目錄只是在HEAD修訂版本裡消失了，如果你使用svn checkout、svn switch或者svn list來檢查一個舊的版本，你仍會見到這個舊的分支。

如果瀏覽你刪除的目錄還不足夠，你可以把它找回來，恢復資料對Subversion來說很簡單，如果你希望恢復一個已經刪除的目錄(或文件)到HEAD，僅需要使用svn copy -r來從舊的版本拷貝出來：

$ svn copy -r 374 http://svn.example.com/repos/calc/branches/my-calc-branch \
                  http://svn.example.com/repos/calc/branches/my-calc-branch

Committed revision 376.

在我們的例子裡，你的個人分支只有一個相對短的生命週期：你會為修復一個Bug或實現一個小的特性來建立它，當任務完成，分支也該結束了。在軟體開發過程中，有兩個「主要的」分支一直存在很長的時間也是很常見的情況，舉個例子，假定我們是發佈一個穩定的calc項目的時候了，但我們仍會需要幾個月的時間來修復Bug，你不希望新增新的特性，但你不希望告訴開發者停止開發，所以作為替代，你為軟體建立了一個「分支」，這個分支更改不會很多：

$ svn copy http://svn.example.com/repos/calc/trunk \
         http://svn.example.com/repos/calc/branches/stable-1.0 \
         -m "Creating stable branch of calc project."

Committed revision 377.

而且開發者可以自由的繼續新增新的(試驗的)特性到/calc/trunk，你可以宣佈這樣一種政策，只有bug修正提交到/calc/branches/stable-1.0，這樣的話，人們繼續在主幹上工作，某個人會選擇在穩定分支上做出一些Bug修正，甚至在穩定版本發佈之後。你或許會在這個維護分支上工作很長時間—也就是說，你會一直繼續為客戶提供這個版本的支持。