svn
中trunk,branches,tags
用法詳解
subversion有乙個很標準的目錄結構,是這樣的。
比如專案是proj,svn位址為svn://proj/,那麼標準的svn布局是
svn://proj/|+-trunk+-branches+-tags
這是乙個標準的布局,trunk為主開發目錄,branches為分支開發目錄,tags為tag存檔目錄(不允許修改)。但是具體這幾個目錄應該如何使用,svn並沒有明確的規範,更多的還是使用者自己的習慣。
對於這幾個開發目錄,一般的使用方法有兩種。我更多的是從軟體產品的角度出發(比如freebsd),因為網際網路的開發模式是完全不一樣的。 1.第一種方法,使用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永遠是開發的主要目錄。
多個人在trunk同一條道路上開發,到達乙個里程碑後歸檔到tag上,trunk的開發繼續進行,如果有問題再從tag上建立分支branch進行基於某個tag的版本開發。
2.第二種方法,在每乙個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的分支上修復
專案管理方法
ibm的專案管理方法與pmbok的比較 ibm的專案管理方法wwpmm由四個有機部分組成 專案管理領域 pm domain 專案管理工作產品 working product 專案管理工作模式 working pattern 專案管理系統 pm system 其中專案管理領域 pm domain 可以...
IT專案管理 管理方法與經驗
產品經理,devops工程師。主要負責需求說明,專案迭代計畫設計以及運營反饋。遇到的最大的問題在於開發迭代計畫與專案章程的不統一。因為在制定專案章程時,開發的時間和具體的成功要求還不夠明確,只能根據課上所學進行一定的嘗試。但是當在制定開發迭代計畫時,我們對專案最終的需求包括第一次迭代的里程碑都已經非...
專案管理之目標管理方法
目標管理方法是現代企業中常用的一種管理方法,這段時間我間歇讀了關於這個方法的一些書,回想這幾年來在軟體開發中的成功與不足,寫出這段文字與優耐達公司的各位同仁共勉。目標管理方法可以簡單概括為一句話,即依據 我現在做的,使我更接近專案目標 的原則,判斷工作輕重緩急,合理安排時間,保證 最重要的事最優先去...