### 分支維護 你一定注意到了Subversion極度的靈活性，因為它用相同的底層機制（目錄拷貝）實現了分支和標簽，因為分支和標簽是作為普通的文件系統出現，會讓人們感到害怕，因為它*太*靈活了，在這個小節里，我們會提供安排和管理數據的一些建議。 ### 版本庫布局 有一些標準的，推薦的組織版本庫的方式，許多人創建一個`trunk`目錄來保存開發的“主線”，一個`branches`目錄存放分支拷貝，一個目錄保存標簽拷貝，如果一個版本庫只是存放一個項目，人們會在頂級目錄創建這些目錄： ~~~ /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修正，甚至在穩定版本發布之后。你或許會在這個維護分支上工作很長時間―也就是說，你會一直繼續為客戶提供這個版本的支持。