### 轉換工作拷貝 **svn switch**命令改變存在的工作拷貝到另一個分支，然而這個命令在分支上工作時不是嚴格必要的，它只是提供了一個快捷方式。在前面的例子里，完成了私有分支的建立，你取出了新目錄的工作拷貝，相反，你可以簡單的告訴Subversion改變你的`/calc/trunk`的工作拷貝到分支的路徑： ~~~ $ cd calc $ svn info | grep URL URL: http://svn.example.com/repos/calc/trunk $ svn switch http://svn.example.com/repos/calc/branches/my-calc-branch U integer.c U button.c U Makefile Updated to revision 341. $ svn info | grep URL URL: http://svn.example.com/repos/calc/branches/my-calc-branch ~~~ 完成了到分支的“跳轉”，你的目錄與直接取出一個干凈的版本沒有什么不同。這樣會更有效率，因為分支只有很小的區別，服務器只是發送修改的部分來使你的工作拷貝反映分支。 **svn switch**命令也可以帶`--revision`（`-r`）參數，所以你不需要一直移動你的工作拷貝到最新版本。 當然，許多項目比我們的`calc`要復雜的多，有更多的子目錄，Subversion用戶通常用如下的法則使用分支： 1. 拷貝整個項目的“trunk”目錄到一個新的分支目錄。 1. 只是轉換工作拷貝的*部分*目錄到分支。 換句話說，如果一個用戶知道分支工作只發生在部分子目錄，我們使用**svn switch**來跳轉部分目錄（有時候只是單個文件），這樣的話，他們依然可以繼續得到普通的“trunk”主干的更新，但是已經跳轉的部分則被免去了更新（除非分支上有更新）。這個特性給“混合工作拷貝”概念添加了新的維度―不僅工作拷貝的版本可以混合，在版本庫中的位置也可以混合。 如果你的工作拷貝包含許多來自不同版本庫目錄跳轉的子樹，它會工作如常。當你更新時，你會得到每一個目錄適當的補丁，當你提交時，你的本地修改會一直作為一個單獨的原子修改提交到版本庫。 注意，因為你的工作拷貝可以在混合位置的情況下工作正常，但是所有的位置必須在同一個版本庫，Subversion的版本庫不能互相通信，這個特性還不在Subversion 1.0的計劃里。 **跳轉和更新** 你注意到**svn switch**和**svn update**的輸出很像？switch命令只是update命令的一個超集。 當你運行**svn update**時，你會告訴版本庫比較兩個目錄樹，版本庫這樣做，并且返回給客戶區別的描述，**svn switch**和**svn update**兩個命令唯一區別就是**svn update**會一直比較同一路徑。 也就是了，如果你的工作拷貝是`/calc/trunk`的一個鏡像，當運行**svn update**時會自動地比較你的工作拷貝的`/calc/trunk`與HEAD版本的`/calc/trunk`。如果你使用**svn switch**跳轉工作拷貝到分支，則會比較你的工作拷貝的`/calc/trunk`與相應分支目錄的HEAD版本。 換句話說，一個更新通過時間移動你的工作拷貝，一個轉換通過時間和空間移動工作拷貝。 因為**svn switch**是**svn update**的一個變種，具有相同的行為，當新的數據到達時，任何工作拷貝的已經完成的本地修改會被保存，這里允許你作各種聰明的把戲。 舉個例子，你的工作拷貝目錄是`/calc/trunk`，你已經做了很多修改，然后你突然發現應該在分支上修改更好，沒問題！你可以使用**svn switch**，而你本地修改還會保留，你可以測試并提交它們到分支。 [[11](#)] 當你的服務器位置改變，而你不想放棄存在的本地拷貝，你*可以*使用帶選項`--relocate`的**svn switch**命令轉換URL，見[第9章 *Subversion完全參考*]( "第9章Subversion完全參考")的**svn switch**查看更多信息和例子。