- 在windows機器上開發得差不多了之後，打包傳送到開發機編譯，在開發機上解決編譯錯誤。
[缺點] 浪費時間在打包解包，機器間傳輸代碼。
- 在windows機器上開發之後，check in代碼進分支，在開發機上check out或者update後，進行編譯，解決編譯錯誤。相當于把svn作為一種機器間通信方式。
[缺點] 送出進svn的代碼甚至都沒有編譯過，我隻能說，svn不是這樣用的。
- 在linux開發機上安裝samba, 在windows環境下開發，開發機上編譯。
[優點] 在windows環境編譯，很便捷；可以實時在開發機上編譯。
[缺點] 如果不用指令行，TortoiseSVN在samba下慢得不能忍。
- 完全在Linux開發機上開發，編譯。
[優點] 回報更靈活，指令行都已經送出完代碼了，烏龜svn可能還在龜速更新。
[缺點] 缺少圖形界面, svn操作完全是指令行的，不太直覺。
通常大多數習慣前三種模式。在windows環境使用TortoiseSVN, 各種操作都封裝的很好，使用起來也很傻瓜。最近在linux環境下開發，發現svn指令行用熟了比TortoiseSVN更好用，最重要的是反應速度更快。
我們的svn工作模式
SVN并行開發管理政策
總的原則：trunk保證相對穩定。分支合并到主幹時将沖突降至最低。
（1） trunk用于內建、測試、釋出，可以送出fixbug代碼，但不允許直接送出新特性。
（2） 特性在分支上開發，在編譯、測試通過後才能合并到主幹。
（3） 特性分支确定一個負責人，負責每天執行從trunk到分支的合并。合并回trunk前，先執行一次trunk到dev的合并，然後在trunk上使用複興分支。
（4） 特性分支的存在時間不能太長，不超過一周為宜。合入主幹後不能繼續使用。
相冊特性開發-采用特性分支
特性分支： 為了使新特性的開發不影響測試或釋出，把新特性開發放在分支上進行管理，分支的生命周期取決于特性的開發周期，該政策的特點是：
1） trunk用于內建、測試、釋出
2） 新特性放在分支上開發
3） 分支負責人定期（如每天）把trunk的變更同步至分支
4） 分支合并回trunk前先執行trunk到分支的合并，然後使用複興分支
5） 分支合并回trunk後，分支生命周期結束，清理分支。
第三方代碼管理-采用供應商分支
這裡的供應商分支通常是指對第三方源代碼的管理，供應商分支的管理通常步驟如下：
1） 建立供應商分支目錄，導入供應商代碼，供應商代碼的維護在此分支上進行
2） 将供應商分支拷貝（branch/tag方式）到trunk或開發分支的某個目錄下
3） trunk或開發分支不對供應商分支代碼做修改
4） trunk或開發分支确認使用供應商分支的新版本時，把供應商分支合并到trunk或開發分支
可能會有人存在疑問，為什麼要對供應商内容做管理？
供應商代碼和自己的産品代碼可以看着是兩個産品線，供應商的代碼可能随時會發生變化，為了不讓供應商代碼的變更影響自己産品的正常研發，就有必要使用分支獨立管理供應商代碼。
供應商分支還可以被另外一種方案所替代，那就是：外部引用（svn:externals）
分支合并到主幹政策
如果說到svn使用最痛苦的一點，那莫過于主幹合分支，或者分支合主幹時爆發的各種莫名其妙的沖突狂潮，如“樹沖突”，“檔案沖突”，“檔案丢失”等等。解決起來費時費力，還容易出錯，效率很低。有沒有較好的解決方法，可以讓日子好過一點呢？答案是有的，需要遵循下面的方法。
沖突産生的根源
svn版本管理原理
svn生成的每個版本隻記錄增量修改，每個檔案都有一個根源版本。
根源版本
根源版本，即祖先版本，在合并的時候是比較重要的一個概念，類似于C++中基類和派生類的關系，這裡所說的根源就是一個基礎版本。
如上圖所示，hello.h的v1版本是v2版本的根源，而v2則是v3、v4的根源。
當進行分支合并時，SVN會沿着分支和trunk追溯共同的根源版本，然後計算其差異，如果沒有共同的根源，則會報樹沖突，就隻能使用忽略根源的方式進行合并了。
沖突1：丢失檔案及可避免的樹沖突（可以避免）
當多人協作開發時，如果分支間合并缺乏時序性，就有可能導緻合并時丢失檔案。
舉個簡單例子來說：
如上圖所示：
A和B兩人同時在2.0-dev分支上開發，A新增一個a.cpp，并送出到SVN版本庫上，産生123版本；然後B基于A送出的a.cpp做修改，送出後生成一個新版本124；
如果B此時想把自己修改的版本124merge到trunk，那麼問題就來了，因為124版本的根源版本是123，隻合并124過來，實際上就相當于隻合并124的變更内容，而此時trunk上還沒有a.cpp，這時SVN就會認為trunk上的a.cpp被删除了（因為找不到），會提示使用者一個樹沖突；
【由于是從2.0-dev合并到trunk， trunk是主合并方，分支是從的關系（在SVN中，trunk的東西稱着mine，而分支是theirs），是以處理樹沖突的時候優先用mine來解決】
當124合并到trunk時，由于找不到a.cpp，SVN會報一個樹沖突，用trunk解決沖突，實際上也就是不會把a.cpp合并過來，這就會導緻合并時出現丢失檔案的現象。
沖突2：文本沖突（無法避免）
當A、B兩人同時修改一個檔案的同一行時，工具不能判斷到底是選擇A的修改or選擇B的修改，或者是A和B的修改都要，這個事情就會報一個沖突，這種沖突也就是文本沖突。
沖突3：樹沖突 （無法避免）
當A、B同時改了一個檔案，A删除了該檔案，而B修改了該檔案，這時由于二者的修改無法進行合并，是以隻能讓使用者二選一，要麼删除該檔案、要麼保留該檔案，這種沖突是樹沖突。
樹沖突産生的場景比較多，以下A和B的任何一種操作組合都會導緻樹沖突。
推薦的合并實踐
1） 建立分支時，在日志中寫明主幹目前版本号。
2） 建立分支後，每天同步一次主幹到分支, 并在日志中寫明合入的主幹目前版本号，便于定位問題。合并指令的用法見小節《常用svn指令》
每天合并問題最容易定位與解決，這也應了靈活開發中小步快跑的思想，以及持續內建的初衷都是一樣的；如果這個頻率不能保證，每周也至少2-3次，否則解決沖突與定位問題的代價就大了。
3）合并回主幹前，先執行一次主幹到分支的合并，然後在主幹上使用複興分支。複興分支使用了合并跟蹤技術(svn1.5以上)，能夠不指定合并版本範圍就将分支中的改動自動合入主幹。
4）特性分支的存在時間不能太長，不超過一周為宜。合入主幹後不能繼續使用，否則當下次從trunk合到此分支時，會引入大量的樹沖突。
原文http://www.5iops.com/html/2013/release_0417/266.html