SVN的標準目錄結構：trunk、branch、tags

目錄在SVN中並沒有特別的意義，這三個目錄反映了軟體開發的通常模式

trunk：主幹，是日常開發進行的地方

branches：分支，一些階段性的release版本，這些版本是可以繼續進行開發和維護的

tags：階段性的釋出版本，存放到這裡

現在來看一下日常開發的流程：

假說現在有一個遊戲專案，專案經理說今天專案要上線了，我們要把程式碼打包部署，然後供玩家使用，玩家正在玩的時候我們還是要繼續進行新需求的開發吧，加入我們不使用svn的目錄結構，我們繼續在原有的程式碼上開發，又過了兩天，有玩家反饋說遊戲有bug，根據玩家提供的bug資訊，我們修復了bug，修復了bug後準備在下一次維護伺服器的時候將修復bug後的程式碼部署到伺服器上。

現在問題來了，我們還沒準備好將正在開發的新功能上線，但是和新功能相關的程式碼已經提到svn了，bug改完也提到svn了，這個時候打包就會將新功能打到包裡，這肯定是不允許的。那怎麼解決呢？

有如下兩個辦法

1、上線時，每個人從svn上遷出一份程式碼，然後儲存到自己的本地，這樣出現bug的時候定位責任人，責任人修改bug的時候在自己的本地修改完打包部署，這樣真的可以解決嗎？如果出現了10多個bug(完全有可能)，這10多個bug分別出在不同的責任人身上，這些人修復完bug後怎麼將程式碼合併到一起？所以這個解決方案pass

2、上線一個版本後，新建一個svn伺服器，想到這還敢往下想嗎？這建議和專案經理提了估計都能把他氣死

下面我們來看看使用svn的標準目錄結構是怎麼處理的

專案上線後，將上線時的程式碼切出一個分支branch，然後在主幹繼續進行新需求的開發，當上線的專案出現bug時，開發人員在分支上修復bug（分支的功能和svn是一樣的），修復完bug後將程式碼打包重新部署，然後將程式碼和併到主幹trunk上，當專案線上執行一段時間已經很穩定時，將專案切出一個tags，tags一般是隻讀的。這樣就比較好的解決了新需求開發與bug修復的矛盾

開始介紹在svn上如何切出分支，如何將分支的程式碼合併到主幹上

本文只介紹eclipse中的svn外掛是如何切出分支和合並程式碼的

在trunk目錄上點選Team-->分支/標記

會出現如下圖所示的對話方塊，在到URL下的輸入框中輸入本次切出的分支的名稱(注意目錄結構，branches路徑後的是切出分支的名稱)

切出分支後在eclipse的branches上點選  Team-->與資源庫同步就可以找到剛才我們切出的專案了

來看一下這是trunk中其中一個類的程式碼

現在切換到branches下 Team-->切換

切換成功後顯示如下：

在branches上修改程式碼，然後提交到svn，一定要提交到svn，否則無法合併，提交到svn後將專案切換到主幹，點選 Team -->合併

Reintegrate a branch：將分支上修復的bug同步到主幹上，同步時會有很多種情況

1、主幹上未做修改，分支上做了修改

2、主幹上做了修改，分支上也做了修改

3、分支上增加了檔案

下面會依次講解著四種情況

Merge a range of revisions ：在主幹上進行了修改，將這個修改同步到分支上，這個操作可以防止分支上的程式碼和主幹上出現嚴重的衝突，但是要保證主幹的上程式碼別影響線上的功能，如果不能保證就不要進行這個操作

點選next後出現如下介面，注意你現在是在主幹上，而這個路徑是分支上你修改的那個類檔案的路徑(因為是修復bug，很少會出現修改大量的類的情況，所有建議一個類一個類的合併到主幹上)

之後一路點選next就可以了，合併之後在分支上修改的程式碼就同步到主幹上了，這個時候主幹上的這個類的狀態是修改狀態，要將這個類同步到svn才算是最終完成

主幹上做了修改分支上也做了修改同步後的結果就是出現衝突檔案，按照正常的解決衝突的辦法來解決就可以了

如果是在branches上新增了檔案，那麼上面的路徑就改成檔案的上一級目錄

主幹同步到分支是類似的，主幹上做的修改先提交到svn，然後切換到branches，合併時路徑指向主幹上被修改檔案的路徑然後一路next就可以了