Android教程網
  1. 首頁
  2. Android 技術
  3. Android 手機
  4. Android 系統教程
  5. Android 游戲
 Android教程網 >> Android技術 >> 關於Android編程 >> Android SVN開發實戰之目錄結構介紹

Android SVN開發實戰之目錄結構介紹

編輯:關於Android編程

svn有一個很標准的目錄結構,是這樣的。比如項目是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://proj/
+trunk/ 
+branches/
    +dev_1.0 (1.0bugfix)
    +dev_2.0 (進行2.0開發)
+tags/
    +tag_release_1.0 (copy from trunk)
選擇性的進行代碼merge
這其實是一種分散式的開發,當各個部分相對 獨立一些(功能性的),可以開多個dev的分支進行開發,這樣各人/組都不會相互影響。比如dev_2.0_search和dev_2.0_cache 等。但是這樣merge起來就是一個很痛苦的事情。
這裡要注意一下的,第六步進行選擇性的merge,是可以當2.0開發結束後一起把 dev_1.0(bugfix用)和dev_2.0(新版本開發 用)merge回trunk。或者先把dev_1.0 merge到dev_2.0,進行測試等之後再merge回trunk。
這兩種方法各有利弊,第一種方法是可以得到一個比較純的dev_2.0的 開發分支,而第二種方法則更加的保險,因為要測試嘛。
以上呢,就是我說的兩種開發模式了,具體哪種好,並沒有定論。這裡大致的說一下各自 的優缺點。

第一種開發模式(trunk進行主要開發,集中式):

優點:管理簡單
缺點:當開發的模塊比較多,開發人數/小團隊比較多 的時候,很容易產生沖突而影響對方的開發。因為所有的改動都有可能觸碰對方的改動。

第二種開發模式(分支進行主要開發,分散式):

優點:各 自開發獨立,不容易相互影響。
缺點:管理復雜,merge的時候很麻煩,容易死人。
其實,這裡並沒有一定之規,更多的時候是兩種 模式結合使用。
  1. 上一頁:
  2. 下一頁:
熱門文章
閱讀排行版
Copyright © Android教程網 All Rights Reserved