svn第一篇----入門指南

摘要：trunk存放的是主代碼，不修改，branch,tag,milestone均是從trunk中衍生的。branch複製trunk中代碼用於開發，tag用於存放比較重要的發行版，存放release版本的代碼和bug——fix版本的代碼快照，milestone應該是比較重要的tag.工作流程看第3部分內容。

1 簡單介紹

所謂的Tag或是Release就是一個特別的版本，因爲這個版本可能有特別的意義。例如：這個版本是特別的Milestone或是release給客戶的版本。其實，Tag與Release的作法與Branch完全相同。只是Branch可能會需要merge回原來的trunk中，而tag及release大部分都不需要merge回trunk中。舉例來說，今天我們的trunk做了一版，這個版本被認定是軟件的1.0版。1.0版對於開發來說是一個非常重要的里程碑。所以我們要特別爲他做一個標記，亦即Tag。假設，這個 1.0版是要正式release給客戶或是相關vendor，我們要可以爲他做一個Release的標記。

2 概念介紹

——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）

3　工作流程　

     假設你必須添加了一個特性至一個項目，且這個項目是受版本控制的，你差不多需要完成如下幾個步驟：

1. 使用SVN checkout或者SVN switch從這個項目的trunk獲得一個新的工作拷貝（branch）

1. 使用SVN切換至新的branch

1. 完成新特性的開發（當然，要做足夠的測試，包括在開始編碼前）

1. 一旦這個特性完成並且穩定（已提交），並經過你的同事們確認，切換至trunk

1. 合併你的分支至你的工作拷貝（trunk），並且解決一系列的衝突

1. 重新檢查合併後的代碼

1. 如果可能的話，麻煩你的同事對你所編寫、更改的代碼進行一次複查（review）

1. 提交合並後的工作拷貝至trunk

1. 如果某些部署需要特殊的環境（生成環境等等），請更新相關的tag至你剛剛提交到trunk的修訂版本

1. 使用SVN update部署至相關環境

  4 深入講解

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的分支上修復 引用地址: 

5  svn代碼回滾命令

取消對代碼的修改分爲兩種情況：   第一種情況：改動沒有被提交（commit）。 這種情況下，使用svn revert就能取消之前的修改。 svn revert用法如下： # svn revert [-R] something 其中something可以是（目錄或文件的）相對路徑也可以是絕對路徑。 當something爲單個文件時，直接svn revert something就行了；當something爲目錄時，需要加上參數-R(Recursive,遞歸)，否則只會將something這個目錄的改動。 在這種情況下也可以使用svn update命令來取消對之前的修改，但不建議使用。因爲svn update會去連接倉庫服務器，耗費時間。 注意：svn revert本身有固有的危險，因爲它的目的是放棄未提交的修改。一旦你選擇了恢復，Subversion沒有方法找回未提交的修改。   第二種情況：改動已經被提交（commit）。 這種情況下，用svn merge命令來進行回滾。     回滾的操作過程如下：     1、保證我們拿到的是最新代碼：       svn update       假設最新版本號是28。     2、然後找出要回滾的確切版本號：       svn log [something]      假設根據svn log日誌查出要回滾的版本號是25，此處的something可以是文件、目錄或整個項目      如果想要更詳細的瞭解情況，可以使用svn diff -r 28:25 [something]    3、回滾到版本號25：        svn merge -r 28:25 something      爲了保險起見，再次確認回滾的結果：        svn diff [something]      發現正確無誤，提交。    4、提交回滾：      svn commit -m "Revert revision from r28 to r25,because of ..."       提交後版本變成了29。    將以上操作總結爲三條如下：    1. svn update，svn log，找到最新版本（latest revision）    2. 找到自己想要回滾的版本號（rollbak revision）    3. 用svn merge來回滾： svn merge -r : something

16、switch  代碼庫URL變更
svn switch (sw): 更新工作副本至不同的URL。
用法: 
1、switch URL [PATH]        
更新你的工作副本，映射到一個新的URL，其行爲跟“svn update”很像，也會將      服務器上文件與本地文件合併。這是將工作副本對應到同一倉庫中某個分支或者標記的方法。 
2、switch --relocate FROM TO [PATH...]   
改寫工作副本的URL元數據，以反映單純的URL上的改變。當倉庫的根URL變動     (比如方案名或是主機名稱變動)，但是工作副本仍舊對映到同一倉庫的同一目錄時使用     這個命令更新工作副本與倉庫的對應關係。
、轉載自：http://www.cnblogs.com/jndream/archive/2012/03/20/2407955.html