学习笔记 SVN分支模式专家详解

开发 项目管理
在学习SVN的过程中你可能会遇到SVN分支问题,在这里向大家简单介绍一下常用SVN分支模式,希望通过本文的介绍大家对SVN分支有清晰的认识。

本节向大家描述一下常用SVN分支模式,主要内容有发布分支和特殊分支的介绍,欢迎大家一起来学习常用SVN分支模式,希望本节的介绍对大家的学习有所帮助。

常用SVN分支模式

版本控制在软件开发中广泛使用,这里是团队里程序员最常用的两种分支/合并模式的介绍,如果你不是使用Subversion软件开发,可随意跳过本小节,如果你是***次使用版本控制的软件开发者,请更加注意,以下模式被许多老兵当作***实践,这个过程并不只是针对Subversion,在任何版本控制系统中都一样,但是在这里使用Subversion术语会感觉更方便一点。

发布分支

首先看一下常用SVN分支模式的发布分支。大多数软件存在这样一个生命周期:编码、测试、发布,然后重复。这样有两个问题,***,开发者需要在质量保证小组测试假定稳定版本时继续开发新特性,新工作在软件测试时不可以中断,第二,小组必须一直支持老的发布版本和软件;如果一个bug在***的代码中发现,它一定也存在已发布的版本中,客户希望立刻得到错误修正而不必等到新版本发布。

这是版本控制可以做的帮助,典型的过程如下:

开发者提交所有的新特性到主干。每日的修改提交到/trunk:新特性,bug修正和其他。

这个主干被拷贝到“发布”分支。当小组认为软件已经做好发布的准备(如,版本1.0)然后/trunk会被拷贝到/branches/1.0。

项目组继续并行工作,一个小组开始对分支进行严酷的测试,同时另一个小组在/trunk继续新的工作(如,准备2.0),如果一个bug在任何一个位置被发现,错误修正需要来回运送。然而这个过程有时候也会结束,例如分支已经为发布前的最终测试“停滞”了。

分支已经作了标签并且发布,当测试结束,/branches/1.0作为引用快照已经拷贝到/tags/1.0.0,这个标签被打包发布给客户。

分支多次维护。当继续在/trunk上为版本2.0工作,bug修正继续从/trunk运送到/branches/1.0,如果积累了足够的bug修正,管理部门决定发布1.0.1版本:拷贝/branches/1.0到/tags/1.0.1,标签被打包发布。

整个过程随着软件的成熟不断重复:当2.0完成,一个新的2.0分支被创建,测试、打标签和最终发布,经过许多年,版本库结束了许多版本发布,进入了“维护”模式,许多标签代表了最终的发布版本。下面我们介绍一下SVN分支模式中的特性分支。

特性分支

一个特性分支是本章中那个重要例子中的分支,你正在那个分支上工作,而Sally还在/trunk继续工作,这是一个临时分支,用来作复杂的修改而不会干扰/trunk的稳定性,不象发布分支(也许要永远支持),特性分支出生,使用了一段时间,合并到主干,然后最终被删除掉,它们在有限的时间里有用。

还有,关于是否创建特性分支的项目政策也变化广泛,一些项目永远不使用特性分支:大家都可以提交到/trunk,好处是系统的简单—没有人需要知道分支和合并,坏处是主干会经常不稳定或者不可用,另外一些项目使用分支达到极限:没有修改曾经直接提交到主干,即使最细小的修改都要创建短暂的分支,然后小心的审核合并到主干,然后删除分支,这样系统保持主干一直稳定和可用,但是造成了巨大的负担。

许多项目采用折中的方式,坚持每次编译/trunk并进行回归测试,只有需要多次不稳定提交时才需要一个特性SVN分支,这个规则可以用这样一个问题检验:如果开发者在好几天里独立工作,一次提交大量修改(这样/trunk就不会不稳定。),是否会有太多的修改要来回顾?如果答案是“是”,这些修改应该在特性分支上进行,因为开发者增量的提交修改,你可以容易的回头检查。

最终,有一个问题就是怎样保持SVN分支模式中一个特性分支“同步”于工作中的主干,在前面提到过,在一个分支上工作数周或几个月是很有风险的,主干的修改也许会持续涌入,因为这一点,两条线的开发会区别巨大,合并分支回到主干会成为一个噩梦。

这种情况***通过有规律的将主干合并到分支来避免,制定这样一个政策:每周将上周的修改合并到分支,注意这样做时需要小心,需要手工记录合并的过程,以避免重复的合并(在“手工跟踪合并”一节描述过),你需要小心的撰写合并的日志信息,精确的描述合并包括的范围(在“合并分支到另一分支”一节中描述过),这看起来像是胁迫,可是实际上是容易做到的。

在一些时候,你已经准备好了将“同步的”特性分支合并回到主干,为此,开始做一次将主干***修改和分支的最终合并,这样以后,除了你的分支修改的部分,***的分支和主干将会绝对一致,所以在这个特别的例子里,你会通过直接比较分支和主干来进行合并: 

  1. $cdtrunk-working-copy  
  2. $svnupdate  
  3. Atrevision1910.  
  4. $svnmergehttp://svn.example.com/repos/calc/trunk@1910\  
  5. http://svn.example.com/repos/calc/branches/mybranch@1910  
  6. Ureal.c  
  7. Uinteger.c  
  8. Anewdirectory  
  9. Anewdirectory/newfile…  
  10.  

通过比较HEAD修订版本的主干和HEAD修订版本的分支,你确定了只在分支上的增量信息,两条开发线都有了分枝的修改。

可以用另一种考虑这种模式,你每周按时同步分支到主干,类似于在工作拷贝执行svnupdate的命令,最终的合并操作类似于在工作拷贝运行svncommit,毕竟,工作拷贝不就是一个非常浅的分支吗?只是它一次只可以保存一个修改。本节讲解SVN分支模式完毕。

【编辑推荐】

  1. 实例剖析TortoiseSvn分支合并
  2. SVN分支与合并学习大本营
  3. 深入讲解SVN分支与合并的关系
  4. SVN分支与合并之专家课堂
  5. SVN分支维护专家在线

 

 

责任编辑:佚名 来源: it168.com
相关推荐

2010-05-28 17:15:17

SVN分支与合并

2010-06-02 09:45:02

SVN学习笔记

2010-06-01 12:36:04

SVN分支与合并

2010-05-20 16:01:36

SVN分支维护

2010-05-28 17:00:24

SVN分支与合并

2010-05-28 17:30:58

SVN分支

2010-05-28 15:47:29

SVN分支

2010-05-28 15:57:20

SVN分支

2010-05-31 16:29:22

SVN权限配置

2010-05-27 09:41:05

SVN冲突

2010-05-20 16:38:40

Subversion常

2010-06-02 09:06:26

SVN学习

2010-06-01 19:55:30

SVN使用

2010-06-01 19:47:29

SVN分支与合并

2010-05-28 19:35:33

Myeclipse下S

2010-05-27 14:18:00

SVN使用说明

2011-07-26 15:29:36

Cocoa 模式

2010-05-20 15:12:02

SVN分支与合并

2010-05-27 13:08:46

SVN简易使用手册

2010-05-25 19:57:32

点赞
收藏

51CTO技术栈公众号