svn作為版本控制軟體被廣泛用于衆多公司的開發團隊中，最多的場景就是一個項目上傳svn後，一個組内的小夥伴在上邊送出和更新代碼以及解決沖突，其實這隻是發揮了svn的很小的一部分功能。
先稍微介紹一下svn的兩種開發和釋出的規範：
一 主幹修改，分支釋出
代碼都在trunk上修改，需要釋出的時候，從主幹上拉出一個版本，如果該版本發現BUG則繼續從該分支上修改，并将修改合并到主幹上。
二 主幹釋出，分支修改
任何修改都不能在主幹上直接進行，開發新功能，從主幹上分支出一個版本，進行開發，發開測試完畢後，在合并到主幹上。
個人比較推崇第二種，其優勢在于各個分支獨立進行，互不幹擾，可以使不同開發周期的應用在同一個項目中開發進行。對于同一個應用，a組人開發完畢，b組人隻做了一半，這個時候，對于主幹修改，分支釋出，這樣是根本不能釋出出去的，而對于主幹釋出，分支修改，隻需要把a組的修改合并回主幹就可以釋出出去了，b組開發的根本不受影響。
下面介紹一下分支，合并的應用場景，并針對場景進行一個小栗子。
場景1： 采用主幹釋出，分支修改的規範後，項目要新開發一個功能，這時候我拉開了一個分支，開發完畢後要分支代碼合并回主幹。
場景2：我在分支的開發過程中，主幹被其他的項目組進行較大的改動，為了避免在“正确”（trunk）的道路上走歪了，也為了避免最終合并代碼的時候，太過麻煩，我需要将主幹的代碼合并到分支上來。
場景3：對于同一個檔案，同一個方法内的代碼合并的時候沖突問題解決。
案例：事先準備工作，我需要在svn建立一個項目test，并建立一個分支test2.0 如圖，項目右鍵--Team-分支
然後重新整理一下svn倉庫，對比看一下trunk主幹和branches分支裡面多了一個2.0的test
場景1 分支代碼合并回主幹。
項目右鍵-team-先切換到分支代碼，然後将分支代碼進行改動，然後在切換回主幹代碼，進行合并操作，如圖
然後将分支的修改代碼送出svn一下，然後同樣切換回主幹trunk代碼，準備合并。
切換回主幹代碼後，分支代碼修改的地方，主幹代碼不受影響，還是老樣子。
右鍵team-選擇合并，然後選擇第二個選項：分支合并到主幹
這時候，你就會看到分支的代碼被合并到主幹上來了，然後送出svn就可以了
場景2：就不介紹了，唯一的差別就是選擇合并方式的時候，選擇第一個選項就可以了
場景3：沖突解決
再次切換到分支代碼，将分支代碼更改
然後切換到主幹代碼trunk，項目右鍵-team-合并，選擇第二項，分支合并到主幹，next。就會出現如下圖結果，将沖突解決完後，右鍵-》标記為解決沖突
沖突的代碼就解決完了。
最後附帶merge input 合并類型截圖