SVN分支與合併
1）從分支合併到主幹
分支開發結束之後，往往需要合併回主幹去測試、發佈，但分支和主幹可能有很多衝突的地方，在合併時經常需要手工解決。
被操作對象：主幹
From：主幹的打出分支時的版本
To：分支的Head版本（最新版本）
怎麼理解這個From和To呢?似乎跟我們的想當然不太一樣：因爲我們理解，把分支合併到主幹，肯定是From分支，To主幹。怎麼搞反了呢？
2）從主幹合併到分支
試想這樣的情況：一個項目裏面，要獨立出來一個子項目，需要單獨發佈版本，用到了基礎框架代碼，而基礎框架在主幹中不斷修改完善，這就需要從主幹合併到分支。
被操作對象：分支
From：分支的第一個版本（最舊版本）
To：主幹的Head版本（最新版本）
相當於從分支的第一個版本開始一直到主幹最後一個版本結束合併之後，替換分支。
合併的工作是把主幹或者分支上合併範圍內的所有改動列出，並對比當前工作副本的內容，由合併者手工修改衝突，然後提交到服務器的相應目錄裏。如果當前工作副本是主幹，則合併的範圍是分支上的改動，如果工作副本是分支的，則合併範圍是主幹上的改動。
一、合併一個範圍的版本
此類型應用最爲廣泛，主要是把分支中的修改合併到主幹上來。在主幹上點擊右鍵選擇合併，然後選擇合併類型：合併一個範圍的版本。合併的源URL填寫的是要合併的分支的URL，待合併的版本範圍如果爲空，則指的是合併分支上所有的版本，即自從分支創建以來到分支當前最新版本的所有演變。如果只是選擇其中一個版本，或者幾個版本，那麼就表示只是將制定的n個版本的變化合併到主幹上。如果只是選擇其中一個版本，那麼表示只是選擇那個版本的修改，之前或之後的修改將不被採納。
二、復興合併
復興合並可以理解爲是第一種合併類型的一種特例，在復興合併中，主幹可以理解爲是自從開創分支之後沒有任何修改，而分支是經過修改的，而且合併中分支是沒有版本選擇的。經過復興合併，分支中所有的修改都會合併到主幹中，合併的結果將使得分支和主幹一模一樣，從而可以刪除分支。
三、合併兩個不同的樹
此類型與前兩種類型不同，第一種類型可以選擇分支合併的版本，主幹不能選擇版本；第二種類型是主幹和分支都不能選擇合併的版本；而這種類型則是無論是主幹還是分支都可以選擇合併的版本，即可以選擇過去的一個主幹版本與分支的某個版本進行合併。合併的時候以選擇的分支版本爲主，如果選擇的主幹版本與分支版本有不同的地方，合併時主幹部分將被放棄。
起始URL：選擇主幹目錄的URL（應當和當前工作副本的URL一致，這個是所謂的合併點）
結束URL：選擇要合併的分支的URL。
起始和結束的版本：一般起始版本應當找到最後一次同步時的版本，如果從沒有同步過（第一次合併），則選擇創建分支時的版本，結束版本一般是最新版本，如果你不想將某些內容合併進主幹的話，也可以選擇一個合併點。實例：
主幹A在95版本的時候創建分支B，此時兩棵樹都是95版本
1、我在分支B上增加文件test.txt，提交。此時版本庫升級到了96版本；
2、我在A上選擇合併類型1，合併分支最新版本，結果是把test.txt加入A；
3、我在A上選擇合併類型2，合併分支最新版本，結果同上；
4、 我在A上選擇合併類型3，合併分支最新版本，結果同上；
5、我在A上增加文件test2.txt，提交，此時版本庫升級到了97版本；
6、我在A上選擇合併類型1，合併分支最新版本，結果是把test.txt加入A；
7、 我在A上選擇合併類型2，合併分支最新版本，結果是把test.txt加入A；
8、 在A上選擇合併類型3，主幹選擇當前97版本，合併分支最新版本，結果是把test.txt加入A，把test2.txt從A刪除；
9、我在A上選擇合併類型3，主幹97以前的版本，合併分支最新版本，結果是把test.txt加入A，而A中保留着test2.txt。
將分支合併到主幹上，首先需要在主幹的工作副本下進行，合併的範圍是從主幹的上次合併的版本開始到分支上最新的版本結束，如果是第一次合併，則從主幹創建分支的版本開始，所以每次合併要做好說明，在日誌中體現，不然忘記了下次再合併就有點麻煩。其實，應當儘量避免一個分支合併多次，分支的作用一般爲了解決bug，一旦bug對應結束了，分支的使命就結束了，以後再出現其他的問題，應當重新建立分支，這樣就不會出現多次合併的問題了。