svn版本控制中有关merge的几个问题
在用svn的时候，我们通常会使用下面的目录结构
projectname
-head
-branches
-tags
通常的做法是我们在需要一个新的分支的时候，从head创建一个分支到branches下面，比如叫release1. 开发完成后，上production结束，将head打一个tag,然后将release1的代码merge回head.
但是在实际开发中我经常发现有一些人从head拿出代码后直接开发，开发完了后断开svn，然后重新提交到branches下面。这样子就有一个问题，分支不是head创建出来的，当我们想把这个分支的代码merge回head的时候，就不能用 "Reintegrate a branch"，如果你用这个会报错，提示说这两个分支没有父子关系，只能使用第一种方式"Merge a range of revisions", 其实使用这种方式理论上来说应该也没有问题，但是我在实际使用的时候发现了一个很奇怪的现象：
当你从head checkout出来，然后改了很多类，然后提交到branches下面生成一个新的分支。这时候你用head去merge这个分支的代码会发现一个都merge不到，但是你用compare去比对又发现很多不一样的类，但是merge死活提示没有更新。然后你在这个新的分支下再修改一个类，再提交，你会发现head能merge到这个新提交了类。我找了很多资料，也去看了svn的日志和文件的版本，没有找到背后的根本原因是什么，可能还是我对svn的原理不熟悉，我想以后多用命令行的方式去执行应该能有更多的发现，现在用eclipse插件，很多后面的东西是发现不到的。
所以还是建议开发人员一定要按规范的方式去使用svn，不要因为有时候会有一点麻烦，而把整个svn的版本搞乱了。
这里有一篇文章是讲分支合并的几种方法 http://www.doc88.com/p-876813951357.html
我觉得第一种就是分支与分支的合并，或者是分支合并主干的内容
第二种主要是主干合并分支的内容，这个可以从它的描述和事例图看得出来(描述和事例图是在eclipse的svn插件上)
另外还有一篇是腾迅的配置管理文档，svn的版本有点老了，不过写得还比较详细
http://wenku.baidu.com/link?url=jP9dk2MpvCIUbLikzzC-2nSCdatAaq4VKO2VAidfWtVHV45HdZBJgikhQb15uXtcCbfeKvoBVSErl_ayaoysiUaAl0K1AYKqVOqO3Az4Ed7
关于复兴分支，我还发现另一段描述
这个用例覆盖了这种情况，当你象《Subversion手册》里讨论的那样，创建了一个新特性分支。所有主干的修改都要每周一次合并到新特性分支，等新特性完成后，你想将它合并到主干。因为你已经保持了新特性分支和主干同步，所以除了你在分支做的修改，其它部分在分支和最新版本应该是相同的。
这是下面讨论的树合并的特殊情况，它只需要你(通常情况下)想要合并的开发分支的 URL。它使用 Subversion 的合并跟踪特性来计算正确的版本范围，并且执行附加的检查来确保分支按照主干的修改进行了完整的更新。这样会确保你不会意外的撤销提交内容，这些内容是其他人在你上次同步修改后提交到主干的。
合并之后，分支的所有开发被完整的合并到主开发版本。现在的分支已经是多余的，可以删除。
一旦你执行了复兴合并，你就不应该继续使用它来进行开发。这样做的原因是，如果过后你试图再次对现有的分支与主干进行同步，合并跟踪将会把你的复兴合并视为未合并到分支的主干修改，并且试图将分支到主干的合并再合并回分支！解决方案很简单，从主干创建一个新的分支来进行下一阶段的开发。
当您在一个特性分支上开发一项新特性并完成时，为其重新整合至主干制定一个策略是一个好主意。如果同一时间 主干 上有其他工作也在继续，您可能会发现随着时间推移，差异会变得更显著，复兴合并将成为一场噩梦。
如果新特性较为简单并且开发时间较短，那么您可以采取一种简单的方法，就是将分支完全独立，直到完成该特性，然后将分支更改合并回主干。在合并向导中，选择简单的 合并一个版本范围，该版本范围即是分支的版本跨度。
如果该特性需要花费更长的时间，就要考虑到 主干 中的变化，那么你就需要保持分支同步。这仅仅意味着定期地将主干的修改合并到分支，使分支包含所有主干的修改并 加上 新特性。同步过程使用 合并一个版本范围 。当完成新特性时，那么你可以使用 复兴分支 或 合并两个不同的树 将其合并回 主干。