SVN深入使用—分支与合并

1.创建分支的意义

创建分支的意义,比如我们在一个基础平台上进行开发,每个技术小组负责一个子项目,而基础平台也是有可能会继续更改的,这个时候,如果不创建分支,子项目之间会相互影响,影响最大的就是后期的测试和版本发布,子项目A已经结束,但测试却受到正在进行的子项目B的影响,测试通不过,就别说版本发布了。所以,我们需要从目前的项目(主干trunk)中创建分支(branch),隔离子项目间的相互影响。

2.svn创建分支原理

在svn中,创建分支,实际上就是一个版本拷贝(对应copy to...注意:绝不是简单在客户端上copy一个目录,而是svn仓库中copy,文件版本号会增加。),两边做任何修改发生的版本变化,是一套机制。举例:目前主干版本是100,分支版本是101,主干中增加一个文件,版本为102,分支中再增加一个文件,版本就为103了。两边的版本号是一套,不会重复。

3.svn创建分支的方法

TortoiseSVN:右键点击工程目录->TortoiseSVN->Branch/tag..菜单,From WC at Url自动为工程svn url,比如https://localhost:8443/svn/fbysss/prj1/trunk,to Url填写https://localhost:8443/svn/fbysss/prj1/branches/branch1。点OK按钮,分支就创建好了。

Subclipse:Team->Branch/tag..,跟上面类似.

SVN命令模式:svn copy trunk_path branch_path -m '描述'

举例:svn copy https://localhost:8443/svn/fbysss/prj1/trunk

https://localhost:8443/svn/fbysss/prj1/branches/branch1 -m "第一个分支"

注意一点:trunk和branch不能互为子目录,否则就乱套了。

4.分支合并

1)从分支合并到主干

分支开发结束之后,往往需要合并回主干去测试、发布,但分支和主干可能有很多冲突的地方,在合并时经常需要手工解决。

被操作对象:主干

From:主干的打出分支时的版本

To:分支的Head版本(最新版本)

怎么理解这个From和To呢?似乎跟我们的想当然不太一样:因为我们理解,把分支合并到主干,肯定是From分支,To主干。怎么搞反了呢?

实际上,Svn认为,我们要合并的,是从主干的某个版本开始,到分支的某个版本结束。两边的版本号实际上是一套系统,不会有重复。我们从TortoiseSVN Help中也能找到证据:


[xhtml]  view plain copy  

If you are using this method to merge a feature branch back to trunk, you need to ........ 
In the From: field enter the full folder URL of the trunk. This may sound wrong, but remember that the trunk is the start point to which you want to add the branch changes. You may also click ... to browse the repository. 
In the To: field enter the full folder URL of the feature branch. 

2)从主干合并到分支

试想这样的情况:一个项目里面,要独立出来一个子项目,需要单独发布版本,用到了基础框架代码,而基础框架在主干中不断修改完善,这就需要从主干合并到分支。

被操作对象:分支

From:分支的第一个版本(最旧版本)

To:主干的Head版本(最新版本)

相当于从分支的第一个版本开始一直到主干最后一个版本结束合并之后,替换分支。

3)从分支合并到分支

有这样的需求:一个项目中有很多分支,这些分支需要分期上线,有多个工作并行,但每一期之间不能相互影响,这就可以打出几个tag(也是分支),从主干copy而来。其他主干根据排期分别合并到这些tag中来。比如有prjTag1和prjTag2,model1、model2需要合并到prjTag1中,model3、model4需要合并到prjTag2中。拿prjTag1举例:

在prjTag1的work copy中,merge

From:主干的打出分支时的版本

To:分支的Head版本(最新版本)

注意:From不是本Tag的某个版本,而是之前主干打出分支时的版本,最终Merge到prjTag1的work copy,而prjTag1是找不到当初打分支时的版本的。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
早在2000年,CollabNet, Inc.就开始召集开发人员开发CVS的替代品。CollabNet 提供一套名为SourceCast协同工作套件,其中的一部分组件是版本控制。虽然SourceCast使用CVS作为其最初的版本控制系统,但是CVS的种种限制从一开始就处处可见,最后CollabNet明白必须要找到一个更好的解决方案。不幸的是,至少在免费license中,因为没有更好的选择,CVS已经广泛成为了开源世界中事实上的标准。所以CollabNet决定开发一个新的版本控制系统,保留CVS的基本特性但去除CVS的bug和不好的特性。   在2000年2月,他们联系《使用CVS开发开源项目》(Open Source Development with CVS)(Coriolis, 1999)的作者Karl Fogel,并征求了他是否愿意在这个新的项目中担任一个角色。巧合的是,当时Karl已经和他的朋友Jim Blandy讨论了一个关于新的版本控制系统的设计。在1995年,这两人就成立了Cyclic Software,一个提供CVS的商业支持的软件公司。虽然他们经营商业服务,但是仍然在每天都在工作中使用CVS。使用CVS的挫折感使得Jim认真思考更好的方法来管理数据,不但确定名字为“Subversion”,而且完成了Subversion档案库的基础设计。   当CollabNet的电话到来时,Karl立即答应了加入项目中,而且Jim让他的雇主RedHat Software同意让他在这个项目中不定期工作。CollabNet雇用了Karl和Ben Collins-Sussman,并在5月开始了详细设计工作。在得到了来自CollabNet的Brian Behlendorf、Jason Robbins和Greg Stein(当时是一名活跃在WebDAV/DeltaV规范过程的自由程序员)很多创意的帮助下,Subversion很快地引起了一个活跃开发者社区的注意。它找出并欢迎很多同样在CVS上受到挫折的社员能来为这个项目做点什么。   Subversion 最初的设计Team定下了几个简单的目标。 它必须在功能上可取代 CVS,也就是说, 所有 CVS 可做到的事, 它都要能够作到。 在修正最明显的瑕疵的同时, 还要保留相同的开发模式。 还有, Subversion 应该要和 CVS 很相像, 任何 CVS 使用者只要花费少许的力气, 就可以很快地上手。   经过十四个月的编码后, Subversion 于2001年8月31日开始实现 “自行管理”。 也就是说, 开发人员不再使用 CVS 来管理 Subversion 的代码, 而以 Subversion 自己来管理。   从启动这个项目到现在,虽然CollabNet提供了大部分的资金(它付出几位全职 Subversion 开发人员的薪水), 但这还是个开源项目, 由一组松散透明的规则所约定。 CollabNet 拥有代码的版权完全符合 Debian Free Software Guidelines。 换句话说, 每个人都可以随意地免费下载、修改、以及重新发布 Subversion; 完全不需要经过 CollabNet, 或是任何人的允许。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值