被svn分支和合并折腾了两天了。适才终于搞定了分支和合并的问题,打包部署成功了。总结下,以防遗忘。项目前段时间因为要加入OSGi的blueprint方法发布和获取服务,从svn主干上做了分支。如今分支的开发完成了,要求合并到主干中。svn的目录结构如下:
主干trunk:
https://192.168.0.11:8443/svn/code/product/trunk/项目名称/code/OSGiServer/plugins/com.tzf.svn.test
tag:
https://192.168.0.11:8443/svn/code/product/tag
分支branches:
https://192.168.0.11:8443/svn/code/product/branches/项目名称/code/OSGiServer/plugins/com.tzf.svn.test
?
先从http://subversion.apache.org/packages#windows下载win2svn文件:Setup-Subversion-1.6.13。安装,在cmd下,svn 命令就可以了。下载这个的作用有两个:查看分支分出时的版本和解决合并冲突。
?
我这里是从分支合并到主干,
被操作对象:主干
From:主干的打出分支时的版本
To:分支的Head版本(最新版本)
怎么理解这个From和To呢?似乎跟我们的想当然不太一样:因为我们理解,把分支合并到主干,肯定是From分支,To主干。怎么搞反了呢?
实际上,Svn认为,我们要合并的,是从主干的某个版本开始,到分支的某个版本结束。两边的版本号实际上是一套系统,不会有重复。
?
比如我主干的结构如下:
?
?
现在在分支里做点修改,比如我加个类叫Bean2.java,并且提交。如图:
?
好啦,现在将工程切换到主干里,因为从分支合并到主干,被操作对象是主干工程。
要合并得知道分支分出去时的版本号,cmd打开命令行,使用svn log --verbose --stop-on-copy branch_path查看版本更新信息,如图:
?
找到最下版本信息,这里就是r8623,记住这个版本号,以后合并的from就是从这个版本号开始的。to就是指你想要合并的版本号,一般都是最新版本,当然也可以是指定版本。
切换到主干,选中工程,右键team -> 合并:
?
next,出现
?
from就是分支的路径,下面选择的就是刚刚记下的分支分出的版本号,to这里就是合并到那个版本,我这里选择的最新版本。点finish,如果文件有冲突就弹出询问框,选择现在暂时不处理就行。
?我这里没有出现文件冲突,点ok就基本大功告成。这时需要在主干里体检带修改符号的文件,完成提交就搞定了合并。
如果文件冲突了怎么办呢,在命令行下进入冲突文件的目录,用svn命令行客户端键入:svn resolved 冲突的文件名? 就可以解除冲突。
好了这是从分支到主干的合并。还有两种合并:从主干到分支和从分支到分支,操作也是大同小异。具体参考如下:
?
从主干合并到分支
试想这样的情况:一个项目里面,要独立出来一个子项目,需要单独发布版本,用到了基础框架代码,而基础框架在主干中不断修改完善,这就需要从主干合并到分支。
被操作对象:分支
From:分支的第一个版本(最旧版本)
To:主干的Head版本(最新版本)
相当于从分支的第一个版本开始一直到主干最后一个版本结束合并之后,替换分支。
从分支合并到分支
有这样的需求:一个项目中有很多分支,这些分支需要分期上线,有多个工作并行,但每一期之间不能相互影响,这就可以打出几个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是找不到当初打分支时的版本的。
?
?
被svn合并折腾了两天,也许还有OSGi复杂的原因,问题算是解决了,但是也是非常的繁琐。希望能看到网友朋友更好的方法分享。
他的方案没问题,不管什么方法,都是选择一个from,选择一个to。分支合并到主干,from既可以从主干选择,也可以从branches选择。