SVN分支管理
目录
- 分支
- 合并
- 需要注意的
- 冲突如何出现
- 如何解决冲突
- 如何避免冲突
分支
使用svn客户端进行分支
把项目从svn服务器上检出来，如果已经检出请忽略，要分支的项目一定要是最新的，更新和提交之后开始分支，右键项目目录->TortoiseSVN->Branch/tag...->
- 从哪里copy分支(主分支)
- copy到什么地方(子分支) To path 来修改路径，记住你要写的路径，这里可以修改为/branches/MyApplication
- Create copy in the repository from: 从哪里创建副本
- HEAD revision in the repository 版本库中当前版本
- Specific revision in the repository 版本库中指定的版本（如果不填则默认为当前分支）
- Working copy 从当前工作区copy副本（这个我很少用）
这里如果没有特殊的需求，就直接默认，如果要指定的版本进行分支，可以点击show log 查看想要分支的版本。
最后在 Recent messages 下面写上日志，点击ok
如果成功了，那么此分支就已经存在版本库中的指定路径中了，然后就可以将版本库里的分支检出到本地了。
这一步基本不会遇到什么问题，出现问题可能出现在to path ： 选择的路径的问题，根据失败的提示来修改。
合并
当我们检出子分支branch之后，修改子分支项目，然后子分支合并到主分支
合并分支之前先提交，使本地的版本为最新的，如果主分支和子分支都不是最新的或者没有提交的会报出异常，一般更新和提交后问题解决，这是非常有好处的，确保你的代码永远不会丢，这是个很好的习惯。
目标：子分支到主分支(因为要把子分支的数据同步过来，所以选择主分支目录右键)
主分支->右键项目目录->TortoiseSVN->Merge
-
Merge a range of revisions 合并一个版本范围
下面是官方文档对此操作的解释
This method covers the case when you have made one or more revisions to a branch (or to the trunk) and you want to port those changes across to a different branch. What you are asking Subversion to do is this: “ Calculate the changes necessary to get [FROM] revision 1 of branch A [TO] revision 7 of branch A, and apply those changes to my working copy (of trunk or branch B). ” If you leave the revision range empty, Subversion uses the merge-tracking features to calculate the correct revision range to use. This is known as a reintegrate or automatic merge.
一般情况下，我使用此选项合并分支，svn会根据你选择的分支，来同步你修改的代码到另个分支中。官方文档的意思：也就是当你有多个版本，并且某个分支进行了修改，svn会根据计算来比较两分支的改动，来同步到你指定的分支上。
- Merge two different trees 合并两个不同的文件树（文件夹）
这种方式见名之意合并两个不同的文件树，svn会把你指定的分支全部copy到想要合并的分支（这里假设主分支），你的主分支会和你的分支长的一摸一样，你说我在子分支上改了改，而又在主分支上改了改，那么使用此方法会丢失你在主分支上的代码，注意文档这个词《The net result is that trunk now looks exactly like the branch》（最终：主分支看起来完全像分支），androidStudio 的插件合并就是这个选项，直接将目标比较差别后给合并，两者长得一摸一样。This is a more general case of the reintegrate method. What you are asking Subversion to do is: “ Calculate the changes necessary to get [FROM] the head revision of the trunk [TO] the head revision of the branch, and apply those changes to my working copy (of the trunk). ” The net result is that trunk now looks exactly like the branch. If your server/repository does not support merge-tracking then this is the only way to merge a branch back to trunk. Another use case occurs when you are using vendor branches and you need to merge the changes following a new vendor drop into your trunk code. For more information read the chapter on vendor branches in the Subversion Book.
咱们的目标是：子分支到主分支，介绍完两种合并分支的方式咱们继续。
选择 Merge a range of revisions->ok
- 指的是合并的数据源是谁，这里定位到子分支MyApplicationCopy
- Revision range to merge
- all revisions 所有的修改（所有的版本，不用比较这么多，一般咱们不选这个）
- specific range 指定的范围（指定版本，默认最新的版本）
- Reverse merge 反向合并（天呀！反向Q,就是给你个机会回退，当你把合并的代码也提交了，怎么办？那就勾上这个给reverse,你会有个疑问，这个和svn的rever有区别么？额，这个我还没试过！你要知道可以告诉我）
这是反向合并官方文档的描述
If you want to merge changes back out of your working copy, to revert a change which has already been committed, select the revisions to revert and make sure the Reverse merge box is checked.
如果您想要将更改从工作副本中返回，则要还原已提交的更改，请选择要恢复的修订，并确保选中反向合并框。
specific range 可以指定一些范围，例如4-7,9,11版本
一般情况下可以默认不填自动计算文本之间的区别，或者直接all revisions ,当我们子分支所有功能开发完后可以直接 选择all revisions
我们选择 specific range 之后点击 next
在合并之前可以点击Test merge 测试合并的结果，合并错误或者合并冲突提前知道
然后点击Merge，合并完成。
解决冲突
说了那么多的废话，其实合并或者分支都很简单，麻烦的是出了问题怎么办？
- 文本冲突 (text)
- 目录结构冲突（tree ）
文本冲突，这个就很好解决了，哪里爆红改哪里，svn自带的解决冲突编译器分为四个部分，【工具栏】，【左侧本地文本】，【右侧服务器提交的文本】，【最下面的合并后的文本】。通过选择左侧和右侧的内容来进行合并，合并完保存并且标记为已解决。
如果使用的是android studio 冲突解决可以右键文件【subversion】-【resolve text conflict】,然后进入合并的页面，左侧本地，中间合并后，右边服务器。
接下来：目录冲突。
- 这个先了解为什么会出现这个现象，你改了一个文件A,你的小伙伴把这个A的名字改成了B,他提交了，然后你拉代码，svn告诉本地的A老子换了个名字，你接受不接受。这个时候你需要抉择了到底是要他的还是要你的，你和你的小伙伴一商量，两个都是干一个事的那就选一个把，这个时候你可以把本地A的改动放到B对应的位置，把A删掉，或者说把B删掉，保留A,标记为已解决。
- 还有个情况就是，人家看文件夹的名字都看不顺眼了，直接改了名字，你拉代码，整个目录下的文件我会告诉你，都木有同步，需要你手动合并之后然后标记为解决！
目录冲突更多的是给你个提示，所以解决起来不会有那么多工具
最后
查了很多文章,感觉官网的教程是最准确的,虽然不容易看懂,但是贵在准确,然后自己多去尝试.最后感谢一位大佬对我的指点.
