本節和大家一起來學習一下使用SVN開發，目錄的約定與開發流程，在我們學習SVN的過程中這是經常會遇到問題，和大家分享一下解決方法，歡迎大家一起來學習SVN開發。

使用SVN開發，目錄的約定與開發流程

SVN有一個很標準的目錄結構，是這樣的。
比如項目是proj，svn地址為svn://proj/，那么標準的svn布局是
svn://proj/
|
+-trunk
+-branches
+-tags
這是一個標準的布局，trunk為主開發目錄，branches為分支開發目錄，tags為tag存檔目錄（不允許修改）。但是具體這幾個目錄應該如何使用，svn并沒有明確的規范，更多的還是用戶自己的習慣。

對于這幾個SVN開發目錄，一般的使用方法有兩種。我更多的是從軟件產品的角度出發（比如freebsd），因為互聯網的開發模式是完全不一樣的。
第一種方法，使用trunk作為主要的開發目錄。
一般的，我們的所有的開發都是基于trunk進行開發，當一個版本/release開發告一段落（開發、測試、文檔、制作安裝程序、打包等）結束后，代碼處于凍結狀態（人為規定，可以通過hook來進行管理）。此時應該基于當前凍結的代碼庫，打tag。當下一個版本/階段的開發任務開始，繼續在trunk進行開發。
此時，如果發現了上一個已發行版本（ReleasedVersion）有一些bug，或者一些很急迫的功能要求，而正在開發的版本（DevelopingVersion）無法滿足時間要求，這時候就需要在上一個版本上進行修改了。應該基于發行版對應的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　(copyfromtrunk)

2.0開始開發，trunk此時為2.0的開發版
發現1.0有bug，需要修改，基于1.0的tag做branch
此時的目錄結構為
svn://proj/
+trunk/(dev2.0)
+branches/
+dev_1.0_bugfix(copyfromtag/release_1.0)
+tags/
+release_1.0　(copyfromtrunk)

在1.0bugfixbranch進行1.0bugfix開發，在trunk進行2.0開發
在1.0bugfix完成之后，基于dev_1.0_bugfix的branch做release等
根據需要選擇性的把dev_1.0_bugfix這個分支merge回trunk（什么時候進行這步操作，要根據具體情況）

這是一種很標準的SVN開發模式，很多的公司都是采用這種模式進行開發的。trunk永遠是開發的主要目錄。

【編輯推薦】

1. Apache+SVN權限管理實例剖析
2. 刪除SVN目錄及從服務器端刪除SVN版本庫文件方法詳解
3. SVN庫的目錄結構詳解
4. 如何實現SVN倉庫目錄規范化管理？
5. 經驗總結：TortoiseSVN客戶端使用心得