咱們在一些著名開源項目的版本庫中,一般能夠看到trunk, branches, tags等三個目錄。因爲SVN固有的特色,目錄在SVN中並無特別的意義,可是這三個目錄卻在大多數開源項目中存在,這是由於這三個目錄反映了軟件開發的一般模式。svn
trunk是主分支,是平常開發進行的地方。學習
branches是分支。一些階段性的release版本,這些版本是能夠繼續進行開發和維護的,則放在branches目錄中。又好比爲不一樣用戶客製化的版本,也能夠放在分支中進行開發。測試
tags目錄通常是隻讀的,這裏存儲階段性的發佈版本,只是做爲一個里程碑的版本進行存檔。編碼
好比一個項目有main.cpp, common.h兩個文件,假設目前在開發的是最新的3.0版本,並且1.0/2.0版本也在進行維護,那麼項目樹將相似以下樣子:翻譯
project
|
+-- trunk
+ |
+ +----- main.cpp (3.0版本的最新文件)
+ +----- common.h
+
+-- branches
+ |
+ +-- r1.0
+ + |
+ + +---- main.cpp (1.x版本的最新文件)
+ + +---- common.h
+ +
+ +-- r2.0
+ |
+ +---- main.cpp (2.x版本的最新文件)
+ +---- common.h
+
+-- tags (此目錄只讀)
|
+-- r1.0
+ |
+ +---- main.cpp (1.0版本的發佈文件)
+ +---- common.h
+
+-- r1.1
+ |
+ +---- main.cpp (1.1版本的發佈文件)
+ +---- common.h
+
+-- r1.2
+ |
+ +---- main.cpp (1.2版本的發佈文件)
+ +---- common.h
+
+-- r1.3
+ |
+ +---- main.cpp (1.3版本的發佈文件)
+ +---- common.h
+
+-- r2.0
+ |
+ +---- main.cpp (2.0版本的發佈文件)
+ +---- common.h
+
+-- r2.1
|
+---- main.cpp (2.1版本的發佈文件)
+---- common.h
要使用這樣的文件夾結構,在創建項目版本庫時,可首先建好項目文件夾,並在其中創建trunk, branches, tags三個空的子目錄,再將項目文件夾連同這三個子目錄一塊兒導入版本庫。設計
這樣在trunk中開始進行開發,當須要創建branch或tag時,使用SVN的copy操做進行。版本控制
其中tags目錄須要只讀,可使用SVN中的authz文件控制該目錄的訪問權限爲只讀。
本節主要講解一下SVN中tag branch trunk的用法,在SVN中Branch/tag在一個功能選項中,在使用中也每每產生混淆。這裏就向你們簡單介紹一下,歡迎你們能和我一塊兒學習SVN中tag branch trunk的用法。
在實現上,branch和tag,對於svn都是使用copy實現的,因此他們在默認的權限上和通常的目錄沒有區別。至於什麼時候用tag,什麼時候用 branch,徹底由人主觀的根據規範和須要來選擇,而不是強制的(好比cvs)。通常狀況下,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。對於svn還要注意的一點,就 是它是全局版本號,其實這個就是一個tag的標記,因此咱們常常能夠看到,什麼什麼release,基於xxx項目的2xxxx版本。就是這個意思了。但 是,它還明確的給出一個tag的概念,就是由於這個更加的可讀,畢竟記住tag_release_1_0要比記住一個很大的版本號容易的多。日誌
branches:分枝
SVN中tag branch trunk的用法,首先看一下branches的介紹。當多我的合做,可能有這樣的狀況出現:John忽然有個想法,跟原先的設計不太一致,多是功能的 添加或者日誌格式的改進等等,總而言之,這個想法可能須要花一段時間來完成,而這個過程當中,John的一些操做可能會影響Sally的工做,John從現 有的狀態單獨出一個project的話,又不能及時獲得Sally對已有代碼作的修正,並且獨立出來的話,John的嘗試成功時,跟原來的合併也存在困 難。這時最好的實踐方法是使用branches。John創建一個本身的branch,而後在裏面實驗,必要的時候從Sally的trunk裏取得更新, 或者將本身的階段成果聚集到trunk中。
(svncopySourceURL/trunkDestinationURL/branchName-m"Creatingaprivatebranchofxxxx/trunk.")視頻
trunk:主幹
主幹,通常來講就是開發的主要呆的地方,
tag: 圖標
在通過了一段時間的開發後,項目到達了一個里程碑階段,你可能想記錄這一階段的代碼的狀態,那麼你就須要給代碼打上標籤。
(svncpfile:///svnroot/mojavescripts/trunkfile:///svnroot/mojavescripts /tags/mirrorutils_rel_0_0_1-m"tagedmirrorutils_rel_0_0_1")另有一說,無所謂誰對誰錯。
trunk:表示開發時版本存放的目錄,即在開發階段的代碼都提交到該目錄上。
branches:表示發佈的版本存放的目錄,即項目上線時發佈的穩定版本存放在該目錄中。
tags:表示標籤存放的目錄。
在這須要說明下分三個目錄的緣由,若是項目分爲一期、二期、三期等,那麼一期上線時的穩定版本就應該在一期完成時將代碼copy到branches上,這 樣二期開發的代碼就對一期的代碼沒有影響,如新增的模塊就不會部署到生產環境上。而branches上的穩定的版本就是發佈到生產環境上的代碼,若是用戶 使用的過程當中發現有bug,則只要在branches上修改該bug,修改完bug後再編譯branches上最新的代碼發佈到生產環境便可。tags的 做用是將在branches上修改的bug的代碼合併到trunk上時建立個版本標識,之後branches上修改的bug代碼再合併到trunk上時就 從tags的version到branches最新的version合併到trunk,以保證前期修改的bug代碼不會再合併。
-------------------------------------------------------------------------------------------
介紹SVN中tag branch trunk用法時,一直以來用svn只是看成cvs,也歷來沒有仔細看過文檔,直到今天用到,纔去翻看svnbook文檔,慚愧
需求一:
有一個客戶想對產品作定製,可是咱們並不想修改原有的svn中trunk的代碼。
方法:
用svn創建一個新的branches,從這個branche作爲一個新的起點來開發
svncopysvn://server/trunksvn://server/branches/ep-m"initep"
Tip:
若是你的svn中之前沒有branches這個的目錄,只有trunk這個,你能夠用
svnmkdirbranches新建個目錄server
需求二:
產品開發已經基本完成,而且經過很嚴格的測試,這時候咱們就想發佈給客戶使用,發佈咱們的1.0版本
svncopysvn://server/trunksvn://server/tags/release-1.0-m"1.0released"咦,這個和branches有什麼區別,好像啥區別也沒有?
是的,branches和tags是同樣的,都是目錄,只是咱們不會對這個release-1.0的tag作修改了,再也不提交了,若是提交那麼就是branches
需求三:
有一天,忽然在trunk下的core中發現一個致命的bug,那麼全部的branches必定也同樣了,該怎麼辦?
svn-r148:149mergesvn://server/trunkbranches/ep其中148和149是兩次修改的版本號。SVN中tag branch trunk用法介紹完畢。
本文主要講解一下SVN組成trunk,branches and tags,主要包括其概念的講解、用法的比較,相信看完本文你確定有很多收穫,但願本文能教會你更多東西。
在本篇文章中,我將會詳細說明我是如何應用SVNtrunk(樹幹)、branches(分支)和tags(標記)。這種方法一樣被稱爲 「branchalways」,二者很是接近。可能我所介紹的並非最好的方法,可是它會給新手一些解釋說明,告訴他們trunk、branches和 tags是什麼,而且該如何去應用它們。
固然,若是本文有些要點須要澄清/確認,亦或者有一些錯誤的觀點,還請你評論,自由發表本身的觀點。——簡單的對比SVN的工做機制在某種程度上就像一顆正在生長的樹:一顆有樹幹和許多分支的樹分支從樹幹生長出來,而且細的分支從相對較粗的樹幹中長出一棵樹能夠只有樹幹沒有分支(可是這種狀況不會持續好久,隨着樹的成長,確定會有分支啦,^^)一顆沒有樹幹可是有不少分支的樹看起來更像是地板上的一捆樹枝若是樹幹患病了,最終分支也會受到影響,而後整棵樹就會死亡若是分支患病了,你能夠剪掉它,而後其餘分支還會生長出來的哦!若是分支生長太快了,對於樹幹它可能會很是沉重,最後整棵樹會垮塌掉當你感受你的樹、樹幹或者是分支看起來很漂亮的時候,你能夠給它照張相,這樣就就能夠記得它在那時是多麼的贊。——TrunkaSVN組成Trunka,Trunk是放置穩定代碼的主要環境,就好像一個汽車工廠,負責將成品的汽車零件組裝在一塊兒。如下內容將告訴你如何使用SVNtrunk:除非你必須處理一些容易且能迅速解決的BUG,或者你必須添加一些無關邏輯的文件(好比媒體文件:圖像,視頻,CSS等等),不然永遠不要在trunk直接作開發不要由於特殊的需求而去對先前的版本作太大的改變,如何相關的狀況都意味着須要創建一個branch(以下所述)不要提交一些可能破壞trunk的內容,例如從branch合併若是你在某些時候偶然間破壞了trunk,bringsomecakethenextday(」withgreatresponsibilitiescome…hugecakes」)——BranchesSVN組成branches,一個branch就是從一個SVN倉庫中的子樹所做的一份普通拷貝。一般狀況它的工做相似與UNIX系統上的符號連接,可是 你一旦在一個SVNbranch裏修改了一些文件,而且這些被修改的文件從拷貝過來的源文件獨立發展,就不能這麼認爲了。當一個branch完成了,而且 認爲它足夠穩定的時候,它必須合併回它原來的拷貝的地方,也就是說:若是原來是從trunk中拷貝的,就應該回到trunk去,或者合併回它原來拷貝的父 級branch。如下內容將告訴你如何使用SVNbranches:若是你須要修改你的應用程序,或者爲它開發一個新的特性,請從trunk中建立一個新的branch,而後基於這個新的分支進行開發除非是由於必須從一個branch中建立一個新的子branch,不然新的branch必須從trunk建立當你建立了一個新branch,你應當當即切換過去。若是你沒有這麼作,那你爲何要在最初的地方建立這個分支呢?——TagsSVN組成Tags。從表面上看,SVNbranches和SVNtags沒有什麼差異,可是從概念上來講,它們有許多差異。其實一個SVNtags就是上文所述的「爲這棵樹照張相」:一個trunk或者一個branch修訂版的命名快照。如下內容將告訴你如何使用SVNtags:做爲一個開發者,永遠不要切換至、取出,或者向一個SVNtag提交任何內容:一個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)——工做流樣例假設你必須添加了一個特性至一個項目,且這個項目是受版本控制的,你差很少須要完成以下幾個步驟:使用SVNcheckout或者SVNswitch從這個項目的trunk得到一個新的工做拷貝(branch)使用SVN切換至新的branch完成新特性的開發(固然,要作足夠的測試,包括在開始編碼前)一旦這個特性完成而且穩定(已提交),並通過你的同事們確認,切換至trunk合併你的分支至你的工做拷貝(trunk),而且解決一系列的衝突從新檢查合併後的代碼若是可能的話,麻煩你的同事對你所編寫、更改的代碼進行一次複查(review)提交合並後的工做拷貝至trunk若是某些部署須要特殊的環境(生成環境等等),請更新相關的tag至你剛剛提交到trunk的修訂版本,使用SVNupdate部署至相關環境Tags:svn,翻譯。SVN組成中trunk,branches and tags概念、功能和用法等介紹完畢。請關注本節的其餘報道。