come from: http://www.360doc.com/content/12/0816/19/1317564_230547958.shtml
創建Branch分支或者Tag標簽
當按照推薦的結構創建的版本庫，創建分支以及Tag是很容易的。
在我的SVN服務器上創建了一個版本庫Test，結構如下：
在我的本地簽出checkout，添加一個文件test.txt，然后提交。
加入這個時候我們需要發布一個版本的文件，同時有可能其他人會修改，
但我們不能影響當前的文件，只能在其修改好后再合並，這種情況下我們創建一個分支。
這個時候我們可以發現本地的trunk文件夾的SVN屬性的URL已經被Switch到創建的版本的地址了：
執行SVN更新命令，可以查看到，本地branches文件夾下新增文件夾v1.0以及文件夾里面的文件v1.0。
修改分支和使用合並Merge功能
修改branches/v1.0下面的文件test.txt，添加一行modified in branch v1.0.然后簽入到SVN服務器中：
由於剛才我們已經將trunk的SVN版本庫URL轉換到對應的版本，所以這個時候更新trunk文件夾可以看到更新的test.txt文件。
為了作測試，我們將trunk文件夾switch至對應的trunk地址：
當switch成功后，我們可以看到trunk下test.txt文件的內容並沒有任何的更改，這正體現了剛才我們所說的在分支中的修改不會影響到主干。
下面修改trunk文件夾下的test.txt，添加一行modified in trunk.然后簽入到SVN服務器中：
最好我們將實現一個重要的功能，就是Merge合並功能，將分支合並到主干中，這也是在團隊軟件開發中我們經常要使用的功能。
在TortoiseSVN的Revision Graph中可以查看trunk的版本變化圖，如下：
從上圖可以得出，在版本10的時候我們創建了分支版本/branches/v1.0，且SVN版本為11，在版本11基礎上我們對分支進行了修改於是有了 版本12，我們再對trunk下的文件進行修改於是有了版本13，整個SVN目前的版本就為13，這與我們剛才做的修改是相吻合的。
下面將分支v1.0合並到主干中。
按照我們目前的情況，選擇第二種：
選擇v1.0：
然后，如下：
在我們的這次合並中肯定會產生問題，因為我們對test.txt文件進行了兩次修改，因而會產生沖突Conflict，但這在實踐中是不應出現這種情況 的，因為建立的分支目的就是修改那些在主干中不會被修改的文件，以便修改完成后合並到主干中。不過沒關系，我們這里僅是演示而已，所以只需處理下沖突，手 動的將其合並（這在實際中不應該這樣否則失去了分支的用途了）：
這個時候可以看到我們的test.txt文件已經按照我剛才手動處理沖突實現了：
然后將trunk簽入到版本庫中：
如果我們再去查看branches\v1.0下的test.txt文件它的內容依然是最初在trunk中編輯的內容。
另外再次強調一點：在實際操作中我們不會對一個分支文件在主干中再次進行修改，否則會造成一些沖突，這樣就失去了分支的便利性了；Tag的創建與分支是類s似的，只不過Tag往往僅用於標識特定版本，而不會用於bug修復，增加新特性等情形。