Android SVN開發實戰的檔案夾結構呈現

標籤：

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進行主要開發。集中式）：          長處：管理簡單
          缺點：當開發的模組比較多，開發人數/小團隊比較多 的時候。非常easy產生衝突而影響對方的開發。由於全部的修改都有可能觸碰對方的修改。
另外一種開發模式（分支進行主要開發，分散式）：          長處：每 自獨立的發展，不easy相互作用。
          缺點：管理複雜，merge很麻煩的時間，easy死。

其實，而不是明顯的在這裡。許多其它時間兩種 模式組合。

Android SVN開發實戰的檔案夾結構呈現