eclipse中SVN使用总结

问：为什么要创建分支？

比如 “XX系统”开发、测试完成、打包上线1.0版本。上线后接到新的需求、继续在原来的版本（版本：1.0）上开发。当新需求开发一半的时候呢，运营人员提出有紧急BUG、需求修改，完成后立即上线。。如果bug也在版本1.0上修改;就算完成了也不敢打包上线，应为这个版本里包含新需求中未完成的功能。

问：遇到上面描述情况改如果做呢？

简单做法（复杂的我也不太清楚！~~）。

项目主干上代码测试没问题。准备上线时，我们先创建版本1.0分支，这个分支上的代码我们做为上线版本1.0的代码，上线后一但有bug我们就Checkout这个分支1.0版本代码并修改。完成后先将修改提交到SVN服务器上，打包（或增量替换更新）升级到生产服务器上，最后将修改合并到主干上。

问：那怎么在Eclipse上创建分支1.0

见下图：

问：发现生产环境有BUG、剪出分支1.0代码并修复了bug后怎么合并到主干上呢？

首页说明下。Eclipse中svn插件合并有多种方式，这里我说明下二种：

有一个概念一定要先明白。将分支的内容合并到主干上，并不能直接将svn服务器分支代码合并到svn服务的主干代码上，而是先将svn服务器分支代码合并到本地工作空间代码中,再将本地工作空间代码提交到svn服务器主干上。如图：

上面说明一个问题：只要你合并后的代码（本地工作空间代码）不提交。SVN服务器的两个分支都不会有影响。尽管大胆尝试。

Merge a range of revisions : 我们可以选择性的将分支上的哪些修订版本合并。举例说明下 ：

比如我们在分支1.0修改了bug1并且提交到svn上，提交的修订版本号21。后来又修改了bug2并提交到svn上。版本号22。

这时我们要在主干上把分支1.0修改的bug1合并回来（修订版本21）。bug2先不合并。这时我们就要选择这个合并方式了。注：这种合并方式是我们用的最多的。不管是将主干内容合并到分支还是将分支合并到主干上都最好用这个。因为可以自由选择版本（如果不想选择版本。选择的是 “All eligible revisions”会将所有可合并的修改都合并过来。）

merge two different trees（慎用） :

将手工指定的FROM和TO两个版本树的差异，应用到本地的工作拷贝。

情况1.如果from分支里A文件内容修改，to分支里A文件也修改了。合并后本地工作空间的结果是to分支A文件内容（from里的A被覆盖，并不在文件内部提示冲突内容块）。

情况2.from分支里新创建一文件B。to分支里创建一个文件C.合并后f本地工作空间的结果from里的B被删除，to面的C文件增加了。

所有最好还是选择第一种方式。第二种方式基本可理解成加to分支代码直接覆盖一from上了。