作者:亲爱的jackvan叔叔 | 来源:互联网 | 2023-10-13 11:16
在用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 的合并跟踪特性来计算正确的版本范围,并且执行附加的检查来确保分支按照主干的修改进行了完整的更新。这样会确保你不会意外的撤销提交内容,这些内容是其他人在你上次同步修改后提交到主干的。
合并之后,分支的所有开发被完整的合并到主开发版本。现在的分支已经是多余的,可以删除。
一旦你执行了复兴合并,你就不应该继续使用它来进行开发。这样做的原因是,如果过后你试图再次对现有的分支与主干进行同步,合并跟踪将会把你的复兴合并视为未合并到分支的主干修改,并且试图将分支到主干的合并再合并回分支!解决方案很简单,从主干创建一个新的分支来进行下一阶段的开发。
当您在一个特性分支上开发一项新特性并完成时,为其重新整合至主干制定一个策略是一个好主意。如果同一时间 主干
上有其他工作也在继续,您可能会发现随着时间推移,差异会变得更显著,复兴合并将成为一场噩梦。
如果新特性较为简单并且开发时间较短,那么您可以采取一种简单的方法,就是将分支完全独立,直到完成该特性,然后将分支更改合并回主干。在合并向导中,选择简单的 合并一个版本范围,该版本范围即是分支的版本跨度。
如果该特性需要花费更长的时间,就要考虑到 主干
中的变化,那么你就需要保持分支同步。这仅仅意味着定期地将主干的修改合并到分支,使分支包含所有主干的修改并 加上 新特性。同步过程使用 合并一个版本范围 。当完成新特性时,那么你可以使用 复兴分支 或 合并两个不同的树 将其合并回 主干
。