SVN理解

先说说什么是branch。按照Subversion的说法,一个branch是某个development line(通常是主线也即trunk)的一个拷贝,见下图:

branch存在的意义在于,在不干扰trunk的情况下,和trunk并行开发,待开发结束后合并回trunk中,在branch和trunk各自开发的过程中,他们都可以不断地提交自己的修改,从而使得每次修改在repository中都有记录。

设想以下场景,如果你的项目需要开发一个新功能,而该功能可能会修改项目中的绝大多数文件,而与此同时,你的另一位同事正在进行bug fix,如果你的新功能不在branch中开发而直接在trunk中开发,那么你极有可能影响另一位同事的bug fix,他/她在bug修复中可能会遇到各种各样的问题,因为你的频繁提交代码引入了过多的不稳定因素。你可能会说,那我在开发的过程中不提交不就行了,等到我全部开发结束我再提交,是,你可以这么做,那还要版本控制干什么呢?也许等到你最后提交代码的时候(也许一周,也许两周?),你会发现有一大堆conflict等着你resolve。。。

那么,正确的做法是什么?使用branch,从trunk创建branch,然后在你的branch上开发,开发完成后再合并到trunk中。

关于branch先讲到这里,下面说说什么叫做合并。很好理解,当branch开发完成后(包括必要的测试),将branch中的修改同步到trunk中,这个过程有可能包括修改文件、增加文件、删除文件等等。

说到这里,貌似本文差不多可以结束了,不就是分支和合并么?只要再简单地说说如何建立分支和如何合并就可以收尾了,可能只需两个命令,也可能只需鼠标点几下然后键盘敲两下即可。其实事情远非这么简单,爱动脑筋的同学可能会问了,将branch的改动merge到trunk的时候,和上文说的直接在trunk中全部开发完然后提交有何区别?你最后还不是要处理一大堆conflict?

这个问题问得非常好,其实这正是本文的重点:branch和trunk在并行开发的过程中如何感知对方,branch如何才能在开发过程中不会和trunk越走越远,导致最后无法合并?试想一下,如果在你开发branch的过程中,trunk中的某个类文件已经被删除了(这可能是另外一个家伙在另一个branch上开发了两周后才合并到trunk的),而你竟然在这个类文件上做了大量修改,试问你到最后合并回trunk的时候该有多蛋疼?解决这一问题的唯一手段是,branch要不停地和trunk保持同步,你要及时地知道trunk都做了什么修改,这些修改是否会影响你正在开发的新功能,如果需要,你必须及时调整branch的代码,使之能与trunk“兼容”。

那么如何让branch和trunk保持同步?合并,从trunk合并到branch,你没听错,是从trunk合并到branch。关于TortoiseSVN的合并,有几点需要注意:

  • TortoiseSVN的合并发生在本地,也即你的working copy中,你无需过多担心会对repository中的代码造成影响
  • 不管是从trunk合并到branch还是最终从branch合并回trunk,在每次合并前最好先update,然后将本地的修改先全部commit,保护好现场,万一合并不理想随时都可以revert
  • 合并完成后看是否能正确编译,然后测试验证,最后将合并后的改动提交到repository

下面我将step by step地演示如何一次完整的branching和merging,包括创建分支、分支开发、分支和主线同步,分支合并到主线的全过程,甚至包括如何在本地创建一个测试用的repository。

首先需要安装TortoiseSVN,我安装的版本是:TortoiseSVN 1.6.15, Build 21041 - 32 Bit , 2011/03/23 18:00:27

1、本地Repository的创建

repository的创建很简单,假设我要在D:\TortoiseSVN\TestRepository目录中创建repository,只需右键TestRepository目录,依次选择"TortoiseSVN" -> "Create repository here"便完成了repository的创建。

2、Check out

假设要check out到D:\TortoiseSVN\TestSVN,同样很简单,在D:\TortoiseSVN目录下创建TestSVN目录,然后在该目录上右键,选择"SVN Check out...",在弹出的窗口中的"URL of repository"中填入"file:///D:/TortoiseSVN/TestRepository",其他默认即可,最后点击ok。

3、trunk创建新项目MyProject

相当简单就不赘述了,只列出本次操作所作出的修改:

4、创建branch

在/trunk/MyProject目录上右键,依次选择"TortoiseSVN" -> "Branch/tag...",在弹出窗口的"To URL"中填入分支的地址,在这里目标revision选择HEAD revision,如下图所示,添加log后点击ok分支便建立了。这个操作速度非常快,新建的branch在repository中其实只是一个指向trunk某个revision的软连接而已,并没有真的复制文件。

5、Check out分支

右键TestSVN目录选择"TortoiseSVN Update"即可将刚刚建立的分支下载回本地。进入/branches/MyProject目录下你会发现其文件结构和/trunk/MyProject一模一样。

6、branch提交一个新文件

7、trunk紧接着提交一个修改

8、branch再次提交一个修改

9、将trunk中的修改同步到branch

6-8演示的是branch和trunk在独立、并行地开发。为了防止在“错误”的道路上越走越远,现在branch意识到是时候和trunk来一次同步了(将trunk合并到branch)。

首先,在本地trunk中先update一下,有冲突的解决冲突,保证trunk和repository已经完全同步,然后在/branches/MyProject上右键,依次选择"TortoiseSVN" -> “Merge...”,在弹出的窗口中选择第一项"Merge a range of revision",这个类型的Merge已经介绍得很清楚,适用于将某个分支或主线上提交的多个revision间的变化合并到另外一个分支上。

点击next后,出现如下窗口:

由于是要从trunk合并到branch,理所当然这里的"URL to merge from"应该填trunk的路径,"Revision range to merge"很好理解,就是你要将trunk的哪些revision所对应的变化合并到branch中,可以是某一连串的revision,比如4-7,15-HEAD,也可以是某个单独的revision号。由于在r4中,trunk修改了Person.java中的talk()方法,所以这里的revision只需填4即可。点击next后出现下图:

在这里只需保留默认设置即可。在点击Merge按钮前你可以先Test merge一把,看成功与否,以及merge的详细信息。点击Merge按钮后trunk所做的修改将同步到branch中。

10、提交合并后的branch

至此,branch已经完全和trunk同步,branch和trunk的代码相处很融洽,没有任何冲突,如果branch已经开发结束,那是时候将branch合并回trunk了,当然,如果branch还要继续开发,那你将不断地重复6-10这几个步骤。

11、将branch合并回trunk

在/trunk/MyProject上右键(注意是在主线的目录上右键),依次选择"TortoiseSVN" -> "Merge...",在弹出的窗口中,Merge type选择第二项"Reintegrate a branch",这种类型的合并适合在分支开发结束后将所有的改动合并回主线。

点击next后出现如下窗口:

在这里,"From URL"选择/branches/MyProject,无需选择revision号,Reintegrate会将branch上所有修改合并到trunk。后面的步骤和上文第9步中的一样,不再啰嗦了。如无意外,branch将成功合并到trunk,你需要做的只是将合并后的trunk赶紧commit!

12、提交合并后的trunk

so easy...

13、删除branch

如果你认为你新加的功能已经开发完成了,你可以删除你的分支

到这里,我已经给你演示完了整个过程,我一身的汗也下来了,我想罢工了,不过最后我们还是看看所有的log信息吧,通过log能发现我们干的所有事情:

r1-r7正是我上文在干的事情,从Message中你能发现我对trunk和branch都干了什么,另外,在Log Messages窗口的左下角勾选了"Include merged revisions"你还能看到额外的Merge information:

图中灰色的是和merge相关的log,共发生了两次merge,第一次是在r6,在r6中,branch合并了trunk在r4时提交的变化;第二次是在r7,在r7中,trunk合并了branch从r2到r6的所有变化。

时间: 2024-10-23 12:00:15

SVN理解的相关文章

淘淘商城基于maven和svn的理解

首先了解下maven和svn是什么: Maven是一个项目的管理工具,它包含了一个项目对象模型 (Project Object Model),一组标准集合,一个项目的生命周期(Project Lifecycle),一个依赖管理系统(Dependency Management System),和用来运行定义在生命周期阶段 中插件的逻辑.当你使用Maven的时候,你用一个明确定义的项目对象模型来描述你的项目,然后Maven可以应用横切的逻辑,这些逻辑来自一组共享的(或者自定义的)插件. Maven

svn老鸟转用git必须理解的概念

不都是SCM代码管理嘛,有很大区别么?很多svn老鸟都是抱着这样的心态去学习git,然后无一幸免地陷入“查阅过很多资料,依然掌握不好”的困境,至少我们团队是这样的. 网上的资料确实已经很多了,却没有把整个知识结构串起来.通读<git权威指南>是可行的,只是大家都急着用,没那耐性.我这里熬一碗鸡汤,整理供大家享用. 一.安装 服务器端不展开,因为主要面向搬砖的码农. 客户端可参见大神 廖雪峰 的Git教程-安装git 需要特别说明的是,在windows中,msysgit才是真正的git客户端,乌

svn关于版本库、工作目录的理解

服务器环境基本上已经搞好,准备着手项目环境的搭建,后继项目将进入团队开发的模式,必须得弄个版本管理的工具了.而对于版本管理工具,本人了解得不多,之前只是使用过SVN,那就SVN吧.废话不多说,进入正题. 了解过SVN的人都知道,svn分为服务端和客户端.服务端主要是记录和维护所有客户端对版本库进行过的操作,客户端则是每个开发人员用来进行自己独立版本的开发.搭建svn服务端的过程并不难.度娘或google,很容易就可以找到相关的资料,因此本文就不再赘诉.本文并不是记录如何搭建一个svn服务器,而是

svn中的Trunk,branches,tags深度理解

trunk.就是主干,这个目录以下直接放源代码了,我们创建项目的时候,把项目源代码放到这个目录.import进svn branches.就是分支,以下可能有非常多trunk,比方trunk_1_0_1,表示trunk1.0.1版本号,就是改动1.0版本号存在的bug,trunk2.0等.就是在分支上改动开发.还能够多切几个分支,每一个分支开发不同的功能,先开发完毕的先合并到主干先公布 tags,就是备份,每次公布上线后都要相应的备份一份代码,假设哪天发现哪个版本号有bug,直接从备份代码做一个分

经过几天的研究,对于SVN的Merge有了更透彻的理解

多分支开发,Merge是一个绕不过的话题,不管是Git还是SVN,之前对于SVN的Merge没有很好的研究,出了些状况,这个问题不解决,顺畅地进行多分支开发就是海市蜃楼,下定决心把这块给完全搞透,在百度上找到的都是太古老的资料,SVN的帮助又没有写得太清楚,没有例子,最终在StackFlow上找到自己想要的.简单总结如下: 1.主干是一切的基石 2.任何分支的来源都必须是主干 3.如果主干修改不多,以分支修改为主的,就要从主干合并到分支(这一步最好是每天都做) 4.在需要建立一个新分支之前,一定

SVN中(trunk tags branches)的使用理解

trunk--主干(永远都是最新的) tags-标签(只读,用于存放发布后的文件冻结,已经对应发布后版本的源文件) branches-分支(针对主干上某个版本进行分支开发) 其实从上面理解来看,和GitHub上差不多. 参考: http://www.cnblogs.com/dafozhang/archive/2012/06/28/2567769.html http://blog.csdn.net/wishfly/article/details/8664795

梳理版本控制器:SVN和Git比较

在日常运维工作中,经常会用到版本控制系统,目前用到最广泛的版本控制器就是SVN和Git,那么这两者之间有什么不同之处呢?今天在此详细记录下: SVN(Subversion)是集中式管理的版本控制器,而Git是分布式管理的版本控制器!这是两者之间最核心的区别. Git不仅仅是个版本控制系统,它也是个内容管理系统(CMS),工作管理系统等.如果你是一个具有使用SVN背景的人,你需要做一定的思想转换,来适应Git提供的一些概念和特征. 先来说说集中式版本控制系统: 版本库是集中存放在中央服务器的,而干

理解git

为了真正了解git,我们从底部.底层开始,了解git核心,知其然并知其所以然. 为什么要进行版本控制呢? 因为编写文件不可能一次到位,文件总是有不同的状态需要保存下来,方便以后出错回滚. git 是目前最先进的版本控制软件(VCS,version control system),它是linux之父Linus Torvalds的第二个作品. 正如git所命名的那样,是“愚蠢或不开心的人”,Linus评价“git is a British English slang for a stupid or

vpn+squid搞定内网才能访问的svn

业精于勤荒于嬉,愿程序猿们鼓起干劲,坚持学下去! 目录 前言 一.squid安装和使用 二.本机的svn代理设置 前言 今天由于要修改公司项目的配置文件,于是不得不秒登vpn,登上svn跳板机,把要修改的文件update下来.修改完成后,在跳板机上传,最后再经过几道程序,终于更新到线上了. 对于不能在个人电脑上update公司svn的代码,着实有些不方便.当然公司是为了代码安全考虑,多加一点防范,我们是可以理解的. 于是,又开始琢磨怎么把svn的代码搞到本机.其实,这问题蛮简单的,只要对于网络知