zz 使用svn 專案的目錄布局

zz:

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的分支上修復

此時的目錄結構

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的時候很麻煩，容易死人。

其實，這裡並沒有一定之規，更多的時候是兩種模式結合使用。我個人來說是採用第一種方式為主，在某些情況下使用第二種方法。

如果你還有其他的好的方法，那麼請賜教。:)

zz 使用svn 專案的目錄布局

SVN 專案的目錄結構

ios專案的目錄結構

Go專案的目錄結構

zz 使用svn 專案的目錄布局

SVN 專案的目錄結構

ios專案的目錄結構

Go專案的目錄結構

相關推薦