关闭

SVN中trunk,branches,tags用法详解

标签: iOS
210人阅读 评论(0) 收藏 举报
分类:
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永远是开发的主要目录。

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

==========================================================================

在SVN中Branch/tag在一个功能选项中,在使用中也往往产生混淆。

在实现上,branch和tag,对于svn都是使用copy实现的,所以他们在默认的权限上和一般的目录没有区别。至于何时用tag,何时用branch,完全由人主观的根据规范和需要来选择,而不是强制的(比如cvs)。

一般情况下,
tag,是用来做一个milestone的,不管是不是release,都是一个可用的版本。这里,应该是只读的。更多的是一个显示用的,给人一个可读(readable)的标记。
branch,是用来做并行开发的,这里的并行是指和trunk进行比较。

比如,3.0开发完成,这个时候要做一个tag,tag_release_3_0,然后基于这个tag做release,比如安装程序等。trunk进入 3.1的开发,但是3.0发现了bug,那么就需要基于tag_release_3_0做一个branch,branch_bugfix_3_0,基于这 个branch进行bugfix,等到bugfix结束,做一个tag,tag_release_3_0_1,然后,根据需要决定 branch_bugfix_3_0是否并入trunk。

对于svn还要注意的一点,就是它是全局版本号,其实这个就是一个tag的标记,所以我们经常可以看到,什么什么release,基于xxx项目的 2xxxx版本。就是这个意思了。但是,它还明确的给出一个tag的概念,就是因为这个更加的可读,毕竟记住tag_release_1_0要比记住一个 很大的版本号容易的多。


branches:分枝
當多個人合作,可能有這樣的情況出現:John突然有個想法,跟原先的設計不太一致,可能是功能的添加或者日誌格式的改進等等,總而言之,這個想法可能需 要花一段時間來完成,而這個過程中,John的一些操作可能會影響Sally的工作,John從現有的狀態單獨出一個project的話,又不能及時得到 Sally對已有代碼做的修正,而且獨立出來的話,John的嘗試成功時,跟原來的合併也存在困難。這時最好的實踐方法是使用branches。 John建立一個自己的branch,然後在裡面實驗,必要的時候從Sally的trunk里取得更新,或者將自己的階段成果彙集到trunk中。
(svn copy SourceURL/trunk DestinationURL/branchName -m "Creating a private branch of xxxx/trunk." )

 

trunk:主幹
主幹,一般來說就是開發的主要呆的地方,

tag:
在經過了一段時間的開發後,項目到達了一個里程碑階段,你可能想記錄這一階段的代碼的狀態,那麼你就需要給代碼打上標籤。
(svn cp file:///svnroot/mojavescripts/trunk file:///svnroot/mojavescripts/tags/mirrorutils_rel_0_0_1
-m "taged mirrorutils_rel_0_0_1")

另有一說,無所謂誰對誰錯。

trunk:表示開發時版本存放的目錄,即在開發階段的代碼都提交到該目錄上。

branches:表示發布的版本存放的目錄,即項目上線時發布的穩定版本存放在該目錄中。

tags:表示標籤存放的目錄。
在這需要說明下分三個目錄的原因,如果項目分為一期、二期、三期等,那麼一期上線時的穩定版本就應該在一期完成時將代碼copy到branches上,這 樣二期開發的代碼就對一期的代碼沒有影響,如新增的模塊就不會部署到生產環境上。而branches上的穩定的版本就是發布到生產環境上的代碼,如果用戶 使用的過程中發現有bug,則只要在branches上修改該bug,修改完bug後再編譯branches上最新的代碼發布到生產環境即可。tags的 作用是將在branches上修改的bug的代碼合併到trunk上時創建個版本標識,以後branches上修改的bug代碼再合併到trunk上時就 從tags的version到branches最新的version合併到trunk,以保證前期修改的bug代碼不會再合併。

-------------------------------------------------------------------------------------------

一直以來用svn只是當作cvs,也從來沒有仔細看過文檔,直到今天用到,才去翻看svn book文檔,慚愧

需求一:
有一個客戶想對產品做定製,但是我們並不想修改原有的svn中trunk的代碼。

方法:
用svn建立一個新的branches,從這個branche做為一個新的起點來開發
svn copy svn://server/trunk svn://server/branches/ep -m "init ep"
Tip:
如果你的svn中以前沒有branches這個的目錄,只有trunk這個,你可以用
svn mkdir branches
新建個目錄

需求二:
產品開發已經基本完成,並且通過很嚴格的測試,這時候我們就想發布給客戶使用,發布我們的1.0版本
svn copy svn://server/trunk svn://server/tags/release-1.0 -m "1.0 released"

咦,這個和branches有什麼區別,好像啥區別也沒有?

是的,branches和tags是一樣的,都是目錄,只是我們不會對這個release-1.0的tag做修改了,不再提交了,如果提交那麼就是branches

需求三:
有一天,突然在trunk下的core中發現一個致命的bug,那麼所有的branches一定也一樣了,該怎麼辦?

svn -r 148:149 merge svn://server/trunk branches/ep
其中148和149是兩次修改的版本號。


======================================================================

——简单的对比

SVN的工作机制在某种程度上就像一颗正在生长的树:

  • 一棵有树干和许多分支的树
  • 分支从树干生长出来,并且细的分支从相对较粗的树干中长出
  • 一棵树可以只有树干没有分支(但是这种情况不会持续很久,随着树的成长,肯定会有分支啦,^^
  • 一颗没有树干但是有很多分支的树看起来更像是地板上的一捆树枝
  • 如果树干患病了,最终分支也会受到影响,然后整棵树就会死亡
  • 如果分支患病了,你可以剪掉它,然后其他分支还会生长出来的哦!
  • 如果分支生长太快了,对于树干它可能会非常沉重,最后整棵树会垮塌掉
  • 当你感觉你的树、树干或者是分支看起来很漂亮的时候,你可以给它照张相,这样就就可以记得它在那时是多么的赞。

——Trunk

Trunk是放置稳定代码的主要环境,就好像一个汽车工厂,负责将成品的汽车零件组装在一起。

以下内容将告诉你如何使用SVN trunk

  • 除非你必须处理一些容易且能迅速解决的BUG,或者你必须添加一些无关逻辑的文件(比如媒体文件:图像,视频,CSS等等),否则永远不要在trunk直接做开发
  • 不要因为特殊的需求而去对先前的版本做太大的改变,如何相关的情况都意味着需要建立一个branch(如下所述)
  • 不要提交一些可能破坏trunk的内容,例如从branch合并
  • 如果你在某些时候偶然间破坏了trunkbring some cake the next day (“with great responsibilities come… huge cakes”)

——Branches

一个branch就是从一个SVN仓库中的子树所作的一份普通拷贝。通常情况它的工作类似与UNIX系统上的符号链接,但是你一旦在一个SVN branch里修改了一些文件,并且这些被修改的文件从拷贝过来的源文件独立发展,就不能这么认为了。当一个branch完成了,并且认为它足够稳定的时候,它必须合并回它原来的拷贝的地方,也就是说:如果原来是从trunk中拷贝的,就应该回到trunk去,或者合并回它原来拷贝的父级branch

以下内容将告诉你如何使用SVN branches

  • 如果你需要修改你的应用程序,或者为它开发一个新的特性,请从trunk中创建一个新的branch,然后基于这个新的分支进行开发
  • 除非是因为必须从一个branch中创建一个新的子branch,否则新的branch必须从trunk创建
  • 当你创建了一个新branch,你应当立即切换过去。如果你没有这么做,那你为什么要在最初的地方创建这个分支呢?

——Tags

从表面上看,SVN branchesSVN tags没有什么差别,但是从概念上来说,它们有许多差别。其实一个SVN tags就是上文所述的为这棵树照张相:一个trunk或者一个branch修订版的命名快照。

以下内容将告诉你如何使用SVN tags

  • 作为一个开发者,永远不要切换至、取出,或者向一个SVN tag提交任何内容:一个tag好比某种照片,并不是实实在在的东西,tags只可读,不可写。
  • 在特殊或者需要特别注意的环境中,如:生产环境(production)、?(staging)、测试环境(testing)等等,只能从一个修复过的(fixedtagcheckoutupdate,永远不要commit至一个tag
  • 对于上述提及到的环境,可以创建如下的tags“production”“staging”“testing”等等。你也可以根据软件版本、项目的成熟程度来命名tag“1.0.3″“stable”“latest”等等。
  • trunk已经稳定,并且可以对外发布,也要相应地重新创建tags,然后再更新相关的环境(production, staging, etc

——工作流样例

假设你必须添加了一个特性至一个项目,且这个项目是受版本控制的,你差不多需要完成如下几个步骤:

  1. 使用SVN checkout或者SVN switch从这个项目的trunk获得一个新的工作拷贝(branch
  2. 使用SVN切换至新的branch
  3. 完成新特性的开发(当然,要做足够的测试,包括在开始编码前)
  4. 一旦这个特性完成并且稳定(已提交),并经过你的同事们确认,切换至trunk
  5. 合并你的分支至你的工作拷贝(trunk),并且解决一系列的冲突
  6. 重新检查合并后的代码
  7. 如果可能的话,麻烦你的同事对你所编写、更改的代码进行一次复查(review
  8. 提交合并后的工作拷贝至trunk
  9. 如果某些部署需要特殊的环境(生成环境等等),请更新相关的tag至你刚刚提交到trunk的修订版本
  10. 使用SVN update部署至相关环境

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:7115次
    • 积分:233
    • 等级:
    • 排名:千里之外
    • 原创:16篇
    • 转载:6篇
    • 译文:0篇
    • 评论:0条
    文章分类