1.进入branch项目的目录 2.右键选择merge 3.下一步 4.选择trunk

转自:http://blog.csdn.net/e3002/article/details/21469437 使用svn几年了,一直对分支和合并敬而远之,一来是因为分支的管理不该我操心,二来即使涉及到分支的管理,也不敢贸然使用合并功能,生怕合并出了问题对团队造成不良影响,最主要的原因是,自己对分支的目的和合并的方法不甚了解,这才是硬伤. 最近由于适配机型的需要(本人从事手机客户端的开发),需要经常接触分支和合并两项工作,突然发现这玩意整不明白很难开展工作,遂这两天着重研究了一下,有点收获,怕以后

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

转自:http://blog.csdn.net/e3002/article/details/21469437 使用svn几年了,一直对分支和合并敬而远之,一来是因为分支的管理不该我操心,二来即使涉及到分支的管理,也不敢贸然使用合并功能,生怕合并出了问题对团队造成不良影响,最主要的原因是,自己对分支的目的和合并的方法不甚了解,这才是硬伤. 最近由于适配机型的需要(本人从事手机客户端的开发),需要经常接触分支和合并两项工作,突然发现这玩意整不明白很难开展工作,遂这两天着重研究了 一下,有点收获,怕以

主干(trunk).分支(branch ).标记(tag) 在SVN中Branch/tag在一个功能选项中,在使用中也往往产生混淆. 在实现上,branch和tag,对于svn都是使用copy实现的,所以他们在默认的权限上和一般的目录没有区别.至于何时用tag,何时用branch,完全由人主观的根据规范和需要来选择,而不是强制的(比如cvs). 一般情况下, trunk:是用来做主方向开发的,一个新模块的开发,这个时候就放在trunk,当模块开发完成后,需要修改,就用branch. branch

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

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

主干(trunk).分支(branch ).标记(tag) 用法示例 + 图解   以svn为例,git的master相当于trunk,dev分支相当于branches -------------------------------------------------------------------------------------------------------------------------------------------- trunk:是用来做主方向开发的一直向前进行,一

合并的工作是把主干或者分支上合并范围内的所有改动列出,并对比当前工作副本的内容,由合并者手工修改冲突,然后提交到服务器的相应目录里.如果当前工作副本是主干,则合并的范围是分支上的改动,如果工作副本是分支的,则合并范围是主干上的改动,并且一定要注意,合并的起始位置URL一定要和当前的工作副本的URL是相同的. 一.合并一个范围的版本 此类型应用最为广泛,主要是把分支中的修改合并到主干上来.在主干上点击右键选择合并,然后选择合并类型:合并一个范围的版本.合并的源URL填写的是要合并的分支的URL,待

Eclipse 中svn的合并与同步: 1.  从主干拉取到分支: 然后一直下一步,到完成就OK了. 2.  从分支代码合并到主干: 2.1.先将本地需要提交更新的代码提交更新到svn分支去 2.2.将本地路径切换到需要合并代码的主干去: 然后需要将本地现有的代码和主干保持完全一致(不然svn不允许进行合并) 2.3.进行合并: 现在我们需要将代码从分支合并到主干,所以我们选择第二个(通常我们只用第一个—从主干同步到分支和第二个). 点击OK后,会出现统计差异的数据一个列表,如下图: 点击OK,

SVN分支合并主干具体操作步骤 1. 在装有svn插件的myeclipse中,在主干上选择需要合并的文件或文件夹, 右击--> team -->合并(merge) 2.选择合并类型--合并两个不同的树 Merge two… --> Next 3. 选择需要合并文件或文件夹的路径 4.  From路径选择主干路径,To路径选择主干对应的分支路径,选择好路径后 我们如果没有特殊要求指定特定版本合并一般开发可以选择最高版本代码进行合并 设置路径和选择好版本后,直接点完成就可以了 5. 合并结果

使用场景: 假如你的项目(这里指的是手机客户端项目)的某个版本(例如1.0版本)已经完成开发.测试并已经上线了,接下来接到新的需求,新需求的开发需要修改多个文件中的代码,当需求已经开始开发一段时间的时候,突然接到用户或测试人员的反馈,项目中有个重大bug需要紧急修复,并且要求bug修复后要立即上线:此时应该怎么修复bug呢?是在当前已经开发新需求的基础上进行修复吗?答案是否定的,原因是:如果是在已经开发新需求的基础上进行修复bug,那么新需求还没开发好,更没有测试,怎么立刻(或最可能快的)上线?

使用场景: 假如你的项目(这里指的是手机客户端项目)的某个版本(例如1.0版本)已经完成开发.测试并已经上线了,接下来接到新的需求,新需求的开发需要修改多个文件中的代码,当需求已经开始开发一段时间的时候,突然接到用户或测试人员的反馈,项目中有个重大bug需要紧急修复,并且要求bug修复后要立即上线:此时应该怎么修复bug呢?是在当前已经开发新需求的基础上进行修复吗?答案是否定的,原因是:如果是在已经开发新需求的基础上进行修复bug,那么新需求还没开发好,更没有测试,怎么立刻(或最可能快的)上线?

比较好的介绍了分支的创建和使用. 转:http://blog.csdn.net/vbirdbest/article/details/51122637

http://blog.csdn.net/vbirdbest/article/details/51122637

SVN merge命令用法 使用svn的merge命令,把一个版本的变化合并到另一个版本.我使用的tortoise,在当前的工作目录点击右键,选择merge,在from框输入源url,在revision中输入需要开始merge的版本起点,比如1400,那就意味着从1400开始后面的变化会merge到工作路径去.去掉to的checkbox选项,在下面的框子里输入当前工作路径的url, revision选择Head revision, 表示合并到当前最高的版本上.点dry run 可以看到试运行合并

一.前言 说来惭愧,鄙人从事开发多年,使用svn已经好几个年头了,但是却仅限于update.commit.compare之类的操作,最近想到github上学习别人写的NIO源码,顺便去熟悉git的使用,但是一想到svn,我心里虚了:用了那么多年却对其一知半解,就连最基本的权限分配都没有做过,更别说进行分支拉取和合并了,何谈去get其他技能?做技术的还是要踏实一点,近一年来,我都在对之前未深入的领域进行扫盲,所以,注定svn是绕不过的坎,于是乎开始各种查资料,安装svn服务端(Virtual SV

前言: 最近公司需要将整体项目从svn迁移至gitlab上,经过几天的研究,现记录一下流程 整体思路是进行一次导入: 先通过subgit将svn整个import至本地,在与git上的项目进行合并. 1.硬件环境 git:git version 2.7.4 svn: 1.6.11   subgit:3.2.22.下载subgit 官网下载subgit: https://subgit.com/ 将subgit解压: tar -zcvf subgit-.zip 3.在gitlab上新建一个需要合并的项

首先说下为什么我们需要用到分支-合并.比如项目demo下有两个小组,svn下有一个trunk版.由于客户需求突然变化,导致项目需要做较大改动,此时项目组决定由小组1继续完成原来正进行到一半的工作[某个模块],小组2进行新需求的开发.那么此时,我们就可以为小组2建立一个分支,分支其实就是trunk版[主干线]的一个copy版,不过分支也是具有版本控制功能的,而且是和主干线相互独立的,当然,到最后我们可以通过[合并]功能,将分支合并到trunk上来,从而最后合并为一个项目. 下面是在eclipse下

以svn为例,git的master相当于trunk,dev分支相当于branches -------------------------------------------------------------------------------------------------------------------------------------------- trunk:是用来做主方向开发的一直向前进行,一个新模块的开发,这个时候就放在trunk,当模块开发完成后,需要修改,就用branc

最近公司产品上线,整个系统架构包含有七八个子系统,并且子系统都是集群部署.所以每次升级维护都要确保尽可能不出问题.因为整个系统刚上线不久,意味着新系统不定期有BUG需修复,但新功能模块也在持续的开发中(可能持续的时间还不短),所以就引发一个问题:持续开发的新功能代码与生产上的代码 如何进行隔离开来进行维护,而且二者还需要不定期的合并代码.所以就研究了下SVN分支. 首先需厘清SVN的分支以下几个概念: trunk: 主干(可以理解为开发环境的代码,平常做开发的工作目录) branches:从主干