SVN 主干(trunk)、分支(branch )、标记(tag)

主干(trunk)、分支(branch )、标记(tag)

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

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

一般情况下,

trunk:是用来做主方向开发的,一个新模块的开发,这个时候就放在trunk,当模块开发完成后,需要修改,就用branch。 
branch:是用来做并行开发的,这里的并行是指和trunk进行比较。
tag:是用来做一个milestone的,不管是不是发布版本,但都是一个可用的版本。这里,应该是只读的。更多的是一个显示用的,给人一个可读的标记。

比如,3.0开发完成,这个时候要做一个tag,tag_release_3_0,然后基于这个tag做发布,比如安装程序等。trunk进入 3.1的开发,但是3.0发现了bug,那么就需要基于tag_release_3_0做一个分支(branch),branch_bugfix_3_0,基于这 个branch进行bug修改,等到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

时间: 2024-11-05 11:28:26

SVN 主干(trunk)、分支(branch )、标记(tag)的相关文章

[Z] SVN的trunk、branch、tag

Subversion有一个很标准的目录结构,是这样的.比如项目是proj,svn地址为svn://proj/,那么标准的svn布局是 svn://proj/|+-trunk+-branches+-tags这是一个标准的布局,trunk为主开发目录,branches为分支开发目录,tags为tag存档目录(不允许修改).但是具体这几个目录应该如何使用,svn并没有明确的规范,更多的还是用户自己的习惯. 对于这几个开发目录,一般的使用方法有两种.我更多的是从软件产品的角度出发(比如freebsd),

SVN的trunk、branch、tag(二)

转——简单的对比 SVN的工作机制在某种程度上就像一颗正在生长的树: 一颗有树干和许多分支的树 分支从树干生长出来,并且细的分支从相对较粗的树干中长出 一棵树可以只有树干没有分支(但是这种情况不会持续很久,随着树的成长,肯定会有分支啦,^^) 一颗没有树干但是有很多分支的树看起来更像是地板上的一捆树枝 如果树干患病了,最终分支也会受到影响,然后整棵树就会死亡 如果分支患病了,你可以剪掉它,然后其他分支还会生长出来的哦! 如果分支生长太快了,对于树干它可能会非常沉重,最后整棵树会垮塌掉 当你感觉你

实用svn主干trunk自动merge到各个分支branch脚本

实用svn主干trunk自动merge到各个分支branch脚本 大多数使用svn的公司,当发现bug时或新功能时,会从主干trunk直接产生一个分支branch,如叫bug01.接着同事A修改里面的bug,如果测试通过,就提交分支,将分支bug01合并到主干,并解决冲突和主干保持一致.同事B也拉了个分支bug02,他也修改了,也测试通过,就提交分支,将分支bug02合并到主干,并解决冲突和主干保持一致.理论上没有任何问题. 问题出现 但是有这样一个情况,同事A修改完就提交分支,合并到主干解决冲

【SVN】SVN的trunk、branches、tag的使用以及分支的概念

svn的存储结构一般建议在根目录下建立trunk.branches.tags这三个文件夹,trunk用于平时的正常工作,branches用于存放各种分支,tags用于存放各种发布版本或某状态的快照 tags本质上和branches是一样的,都是一种分支,只是习惯上branches下面的东西会被修改.合并,而tags下面的东西则作为某阶段的状态保存不动 一般tags下面经常放的都是各个发布版本,如Release0.91.Release1.23等 1首先明白我们采用命令行的方式在服务器上创建的仓库是

解决版本冲突-使用SVN主干与分支功能

1  前言 大多数产品开发存在这样一个生命周期:编码.测试.发布,然后不断重复.通常是这样的开发步骤: 1)    开发人员开发完毕某一版本(如版本A)功能后,提交测试: 2)    测试人员对待发布版本A进行测试,同时开发人员继续开发新功能(如版本B): 3)    测试人员提交bug,研发人员修复bug,同时继续开发新功能: 4)    重复第3步骤,直到待发布版本A测试通过测试后,发布第一版本 这样就会存在以下问题: 1)    如何从代码库中(A+B)分离出待发布版本A,进行测试和发布:

[转载]SVN trunk、branch、tag的用法

Subversion有一个很标准的目录结构,是这样的. 比如项目是proj,svn地址为svn://proj/,那么标准的svn布局是 svn://proj/|+-trunk+-branches+-tags 这是一个标准的布局,trunk为主开发目录,branches为分支开发目录,tags为tag存档目录(不允许修改).但是具体这几个目录应该如何使用,svn并没有明确的规范,更多的还是用户自己的习惯. 对于这几个开发目录,一般的使用方法有两种.我更多的是从软件产品的角度出发(比如freebsd

SVN中trunk、branches、tag的使用

我相信初学开发在SVN作为版本管理时,都估计没可能考虑到如何灵活的运用SVN来管理开发代码的版本,下面我就摘录一篇文章来简单说明SVN里的trunk,branched,tags这个三个文件目录的用法. 我将会详细说明我是如何应用SVNtrunk(树干).branches(分支)和tags(标记).这种方法同样被称为“branchalways”,两者非常接近.可能我所介绍的并不是最好的方法,但是它会给新手一些解释说明,告诉他们trunk.branches和tags是什么,并且该如何去应用它们. —

SVN版本管理trunk及branch相关merge操作

先说说什么是branch.按照Subversion的说法,一个branch是某个development line(通常是主线也即trunk)的一个拷贝,见下图: branch存在的意义在于,在不干扰trunk的情况下,和trunk并行开发,待开发结束后合并回trunk中,在branch和trunk各自开发的过程中,他们都可以不断地提交自己的修改,从而使得每次修改在repository中都有记录. 设想以下场景,如果你的项目需要开发一个新功能,而该功能可能会修改项目中的绝大多数文件,而与此同时,你

IOS使用Svn的trunk、branches、tag分别的侧重

trunk(主干)团队中大部分成员工作的主要仓库,前期大的团队的代码管理的主要控件,它的功能的侧重点是开发阶段的代码的管理的和集成,由于svn的冲突解决方式来进行代码冲突的处理,一般是最后提交的需要进行代码的处理,Xcode5以后的版本加强了对于svn的集成,所以现在Xcode可以更加方便的进行代码的提交和冲突解决,但是为了更好的进行分支和代码更新历史的管理,最好使用客户端进行辅助管理,比较推荐的Versions比较方便,不需要进行层次深入的更新操作. branches(分支)分支既是从主干上衍