svn代碼版本管理
1.0開發，做dev1.0的branch
此時的目錄結構
svn://proj/
+trunk/ (不負擔開發任務)
+branches/
+dev_1.0 (copy from trunk)
+tags/
1.0開發完成，merge dev1.0到trunk
此時的目錄結構
svn://proj/
+trunk/ (merge from branch dev_1.0) ===>測試，打tag或者修改合並后的bug，擔負bug代碼修改
+branches/
+dev_1.0 (開發任務結束，freeze)
+tags/
1) 合並后，測試如果有bug，可以直接在trunk上修改bug，直到修正后打tag進行發布
2）合並后，測試無問題直接打tag發布
發布后發現存在bug：需要修改，基於1.0的tag做branch_buffix_1.0
此時的目錄結構
svn://proj/
+trunk/
+branches/
+dev_1.0 (開發任務結束，freeze)
+dev_2.0 （進行2.0開發）
+branch_buffix_1.0
+tags/
+tag_release_1.0 (copy from trunk)
1）如果2.0開發開始，但並沒合並入主干：branch_buffix_1.0中修正bug后合並到主干，通過主干打tag發布
2）如果2.0開發結束，而且合並入主干：branch_buffix_1.0中修正bug后依然合並到主干，但通過分支branch_buffix_1.0打tag發布
依次類推！！
總結：
1）tag上不做任務代碼修改
2）新需求開發，從主干（最新穩定的）做分支在分支上開發
3）新需求分支開發完成或者分支bug修正后，都必須合並到主干
4）主干可在合並后發現問題（並沒打tag）做部分修改
這是方法之一，比較適用於那些經常改動，bug較多的網站開發。
以下是收集出來的各方法說明：
SVN中Branch和tag建立的方法比較簡單，totoiseSVN中的操作是:
1.選擇Branch和tag..
2.在出來的界面中的ToURL中填上URL，一般是svn://IP/Project/branches/branch-1,這樣就建立了一個 branch-1的branch.建立tag是一樣的操作，只不過URL一般是svn://IP/Project/tags/tag-1
3.后面的Createcopyfrom是用於選擇從你當前的workingbase中的哪個版本中建立Branch和tag，可以根據自己的選擇來訂 制，一般選擇HeadRevision
建分支
svn copy svn://server/trunk svn://server/branches/ep -m "init ep"
>svn trunk，branch，tag
1. branch和tag，對於svn都是使用copy實現的，所以他們在默認的權限上和一般的目錄沒有區別
3. 介紹一下
trunk：表示開發時版本存放的目錄，即在開發階段的代碼都提交到該目錄上。
branches：表示發布的版本存放的目錄，即項目上線時發布的穩定版本存放在該目錄中。
tags：表示標簽存放的目錄。
3.一般情況下，
tag，是用來做一個milestone的，不管是不是release，都是一個可用的版本。這里，應該是只讀的。更多的是一個顯示用的，給人一個可讀（readable）的標記。
branch，是用來做並行開發的，這里的並行是指和trunk進行比較。
比如，3.0開發完成，這個時候要做一個tag，tag_release_3_0，然后基於這個tag做release，比如安裝程序等。trunk進入 3.1的開發，但是3.0發現了bug，那么就需要基於tag_release_3_0做一個branch，branch_bugfix_3_0，基於這個branch進行bugfix，等到bugfix結束，做一個tag，tag_release_3_0_1，然后，根據需要決定 branch_bugfix_3_0是否並入trunk。
trunk ：表示開發時版本存放的目錄，即在開發階段的代碼都提交到該目錄上。
branches ：表示發布的版本存放的目錄，即項目上線時發布的穩定版本存放在該目錄中。
tags ：表示標簽存放的目錄。
轉載 SVN的trunk branch tag 收藏
Subversion有一個很標准的目錄結構，是這樣的。
比如項目是proj，svn地址為svn://proj/，那么標准的svn布局是
svn://proj/|+-trunk+-branches+-tags
這是一個標准的布局，trunk為主開發目錄，branches為分支開發目錄，tags為tag存檔目錄（不允許修改）。但是具體這幾個目錄應該如何使用，svn並沒有明確的規范，更多的還是用戶自己的習慣。
對於這幾個開發目錄，一般的使用方法有兩種。我更多的是從軟件產品的角度出發（比如freebsd），因為互聯網的開發模式是完全不一樣的。
第一種方法，使用trunk作為主要的開發目錄。
一般的，我們的所有的開發都是基於trunk進行開發，當一個版本/release開發告一段落（開發、測試、文檔、制作安裝程序、打包等）結束后，代碼處於凍結狀態（人為規定，可以通過hook來進行管理）。此時應該基於當前凍結的代碼庫，打tag。當下一個版本/階段的開發任務開始，繼續在trunk進行開發。
此時，如果發現了上一個已發行版本（Released Version）有一些bug，或者一些很急迫的功能要求，而正在開發的版本（Developing Version）無法滿足時間要求，這時候就需要在上一個版本上進行修改了。應該基於發行版對應的tag，做相應的分支（branch）進行開發。
例如，剛剛發布1.0，正在開發2.0，此時要在1.0的基礎上進行bug修正。
按照時間的順序
1.0開發完畢，代碼凍結
基於已經凍結的trunk，為release1.0打tag
此時的目錄結構為
svn://proj/
+trunk/ (freeze)
+branches/
+tags/
+tag_release_1.0 (copy from trunk)
2.0開始開發，trunk此時為2.0的開發版
發現1.0有bug，需要修改，基於1.0的tag做branch
此時的目錄結構為
svn://proj/
+trunk/ ( dev 2.0 )
+branches/
+dev_1.0_bugfix (copy from tag/release_1.0)
+tags/
+release_1.0 (copy from trunk)
在1.0 bugfix branch進行1.0 bugfix開發，在trunk進行2.0開發
在1.0 bugfix 完成之后，基於dev_1.0_bugfix的branch做release等
根據需要選擇性的把dev_1.0_bugfix這個分支merge回trunk（什么時候進行這步操作，要根據具體情況）
這是一種很標准的開發模式，很多的公司都是采用這種模式進行開發的。trunk永遠是開發的主要目錄。
第二種方法，在每一個release的branch中進行各自的開發，trunk只做發布使用。
這種開發模式當中，trunk是不承擔具體開發任務的，一個版本/階段的開發任務在開始的時候，根據已經release的版本做新的開發分支，並且基於這個分支進行開發。還是舉上面的例子，這里面的時序關系是。
1.0開發，做dev1.0的branch
此時的目錄結構
svn://proj/
+trunk/ (不擔負開發任務 )
+branches/
+dev_1.0 (copy from trunk)
+tags/
1.0開發完成，merge dev1.0到trunk
此時的目錄結構
svn://proj/
+trunk/ (merge from branch dev_1.0)
+branches/
+dev_1.0 (開發任務結束，freeze)
+tags/
根據trunk做1.0的tag
此時的目錄結構
svn://proj/
+trunk/ (merge from branch dev_1.0)
+branches/
+dev_1.0 (開發任務結束，freeze)
+tags/
+tag_release_1.0 (copy from trunk)
1.0開發，做dev2.0分支
此時的目錄結構
svn://proj/
+trunk/
+branches/
+dev_1.0 (開發任務結束，freeze)
+dev_2.0 （進行2.0開發）
+tags/
+tag_release_1.0 (copy from trunk)
1.0有bug，直接在dev1.0的分支上修復
詳細說明我是如何應用SVN trunk(樹干)、branches(分支)和tags(標記)。這種方法同樣被稱為“branch always”，兩者非常接近。可能我所介紹的並不是最好的方法，但是它會給新手一些解釋說明，告訴他們trunk、branches和tags是什么， 並且該如何去應用它們。
當然，如果本文有些要點需要澄清/確認，亦或者有一些錯誤的觀點，還請你評論，自由發表自己的觀點。
——簡單的對比
SVN的工作機制在某種程度上就像一顆正在生長的樹：
* 一顆有樹干和許多分支的樹
* 分支從樹干生長出來，並且細的分支從相對較粗的樹干中長出
* 一棵樹可以只有樹干沒有分支（但是這種情況不會持續很久，隨着樹的成長，肯定會有分支啦，^^）
* 一顆沒有樹干但是有很多分支的樹看起來更像是地板上的一捆樹枝
* 如果樹干患病了，最終分支也會受到影響，然后整棵樹就會死亡
* 如果分支患病了，你可以剪掉它，然后其他分支還會生長出來的哦！
* 如果分支生長太快了，對於樹干它可能會非常沉重，最后整棵樹會垮塌掉
* 當你感覺你的樹、樹干或者是分支看起來很漂亮的時候，你可以給它照張相，這樣就就可以記得它在那時是多么的贊。
——Trunk
Trunk是放置穩定代碼的主要環境，就好像一個汽車工廠，負責將成品的汽車零件組裝在一起。
以下內容將告訴你如何使用SVN trunk：
*
除非你必須處理一些容易且能迅速解決的BUG，或者你必須添加一些無關邏輯的文件（比如媒體文件：圖像，視頻，CSS等等），否則永遠 不要在trunk直接做開發
*
不要因為特殊的需求而去對先前的版本做太大的改變，如何相關的情況都意味着需要建立一個branch（如下所述）
*
不要提交一些可能破壞trunk的內容，例如從branch合並
*
如果你在某些時候偶然間破壞了trunk，bring some cake the next day (”with great responsibilities come… huge cakes”)
——Branches
一個branch就是從一個SVN倉庫中的子樹所作的一份普通拷貝。通常情況它的工作類似與UNIX系統上的符號鏈接，但是你一旦在一個SVN branch里修改了一些文件，並且這些被修改的文件從拷貝過來的源文件獨立發展，就不能這么認為了。當一個branch完成了，並且認為它足夠穩定的時 候，它必須合並回它原來的拷貝的地方，也就是說：如果原來是從trunk中拷貝的，就應該回到trunk去，或者合並回它原來拷貝的父級branch。
以下內容將告訴你如何使用SVN branches：
*
如果你需要修改你的應用程序，或者為它開發一個新的特性，請從trunk中創建一個新的branch，然后基於這個新的分支進行開發
*
除非是因為必須從一個branch中創建一個新的子branch，否則新的branch必須從trunk創建
*
當你創建了一個新branch，你應當立即切換過去。如果你沒有這么做，那你為什么要在最初的地方創建這個分支呢？
——Tags
從表面上看，SVN branches和SVN tags沒有什么差別，但是從概念上來說，它們有許多差別。其實一個SVN tags就是上文所述的“為這棵樹照張相”：一個trunk或者一個branch修訂版的命名快照。
以下內容將告訴你如何使用SVN tags：
*
作為一個開發者，永遠不要切換至、取出，或者向一個SVN tag提交任何內容：一個tag好比某種“照片”，並不是實實在在的東西，tags只可讀，不可寫。
*
在特殊或者需要特別注意的環境中，如：生產環境（production）、？（staging）、測試環境（testing）等等，只 能從一個修復過的（fixed）tag中checkout和update，永遠不要commit至一個tag。
*
對於上述提及到的環境，可以創建如下的tags：“production”，“staging”，“testing”等等。你也可以根 據軟件版本、項目的成熟程度來命名tag：“1.0.3”，“stable”，“latest”等等。
*
當trunk已經穩定，並且可以對外發布，也要相應地重新創建tags，然后再更新相關的環境（production, staging, etc）
——工作流樣例
假設你必須添加了一個特性至一個項目，且這個項目是受版本控制的，你差不多需要完成如下幾個步驟：
1.
使用SVN checkout或者SVN switch從這個項目的trunk獲得一個新的工作拷貝（branch）
2.
使用SVN切換至新的branch
3.
完成新特性的開發（當然，要做足夠的測試，包括在開始編碼前）
4.
一旦這個特性完成並且穩定（已提交），並經過你的同事們確認，切換至trunk
5.
合並你的分支至你的工作拷貝（trunk），並且解決一系列的沖突
6.
重新檢查合並后的代碼
7.
如果可能的話，麻煩你的同事對你所編寫、更改的代碼進行一次復查（review）
8.
提交合並后的工作拷貝至trunk
9.
如果某些部署需要特殊的環境（生成環境等等），請更新相關的tag至你剛剛提交到trunk的修訂版本
10.
使用SVN update部署至相關環境
轉自：http://blog.csdn.net/xiaomu_fireant/article/details/6195622