分支合并样例及注意问题.doc

一般svn版本库目录建议创建trunk、branches和tags三个目录。在实际操作时，trunk主干版本要时刻 保持干净，即随时可以基于这个版本进行修改并将应用部署上线。branches是分支目录，存放并行开发的项目代码，因为分支是主干的廉价拷贝（相当只是提交了一 次主干版本，增加了一个版本号， 并没有取出版本库作镜像拷贝），所以你可以放心建立很多分支版本。不过 Subversion不支持跨版本库的拷贝，当使用svn copy时你只能在同一个版本库内操作。tags目录存放trunk某个的快照，比如说release-1.0即trunk处于1.0版本时的快照。使用svn来作团队的代码管理，那么分支和合并将是非常常用的操作。需求一： (分支的使用)有一个客户想对产品做定制，但是我们并不想修改原有的svn中trunk的代码。 在需要修改的代码那个节点创建分支即可。SVN 的副本是通过cheap copies 来实现的，建立一个副本就类似 Unix 中创建一个硬链接(hard link)，空间和时间的消耗都是固定并且很小的，因此不必太过担心副本太多而导致性能问题。（这样做的好处：如果像不用SVN管理前，都是将需要修改的代码拷贝一份再修改，这样会占用硬盘空间。最糟糕的是如果这时主线修改了一些bug，那在客户定制的代码也会包含有这个bug，那么只能将修改的代码复制到客户定制的代码。这样如果两边的代码修改的部分不一样，就会覆盖原先的代码。不能自动合并。如果用SVN,创建分支，相当于一个映射，不占用空间。并且如果主线有更新，只要一步合并就可以了。如果有冲突，还可以比较并解决冲突。方法： 用svn建立一个新的branches，从这个branche做为一个新的起点来开发需求二： （标签的使用）产品开发已经基本完成，并且通过很严格的测试，这时候我们就想发布给客户使用，发布我们的1.0版本, 这个和branches有什么区别，好像啥区别也没有？ 是的，branches和tags是一样的，都是目录，只是我们不会对这个release-1.0的tag做修改了，不再提交了需求三： （合并的使用）有一天，突然在trunk下的core中发现一个致命的bug,那么所有的branches一定也一样了，该怎么办？在本地将最新的主干取出 svn co /repos/example/trunk example(2)、到当前的example目录下合并分支,4889,4906分别表示分支的最初版本号和最终版本号svn merge -r 4889:4906 /repos/example/branches/branches_test4、典型的svn目录结构project/branches/project/tags/project/trunk/5、项目代码测试发布前别忘打上tag,作为一个基准.代表一次发布版本。6、实用的SVN命令* svn copy 创建分支或者标签 svn copy /repos/calc/trunk /repos/calc/tags/release-1.0 -m Tagging the 1.0 release of the calc project.* svn switch 切换工作拷贝到指定的分支或者返回主干 svn switch /repos/calc/branches/my-calc-branch* svn diff 版本比较svn diff rules.txt 比较本地修改svn diff -r 3 rules.txt 比较工作拷贝和版本库svn diff -r 2:3 rules.txt 比较版本库与版本库 * svn revert 删除你的本地修改,恢复到修改前的状态.* 查一个过去的版本,重定向输出到一个文件svn cat -r 2 rules.txt rules.txt.v2*svn info 查看当前工作拷贝是在主干还是在哪个分支上。一些相关的概念和原理 分支(branch)和标记(tag)对于 SVN 来说就只是副本(copy)，没有任何其它意义。分支和标记的意义是我们人为给予的。 SVN 的副本是通过cheap copies 来实现的，建立一个副本就类似 Unix 中创建一个硬链接(hard link)，空间和时间的消耗都是固定并且很小的，因此不必太过担心副本太多而导致性能问题。 SVN 的文件储存 是通过差异(diff)来实现的，底层储存方法有两种：1、Berkeley DB，完整保存一个文件的最新版本(revision)，旧版本通过反向差异(reverse diffs)来获取。2、FSFS，跟 BDB 相反，完整保存一个文件的初始版本，后续版本通过正向差异来获取。当然，为了避免版本太多而造成性能下降，SVN 还使用了skip-deltas 来减少需要追溯的版本数。 SVN 属性(property )可以附带在文件、目录和版本(revision)上。文件和目录的属性类似文件内容，会被记录进版本库中的，例如每次提交时的注释，其实就是该版本的一个属性 svn:log。以svn:开头的属性是系统预留的，用户不应该自定义这样的属性。 进行分支开发的最佳实践 做分支上做开发的时候，必须定期使分支与主干同步，避免开发完成后合并(merge)回主干时出现严重冲突(confict)。 进行合并前，处理掉工作副本上的所有本地修改，方便合并失败时进行回滚(revert)。 进行合并时，特别注意 新增/删除 操作，因为很多冲突都是这类操作引起的。 完成一个分支的功能并合并回主干后，抛弃该分支，后续其它功能的开发使用新建的分支。当然，也有办法继续使用该分支。合并的分类1、从主干到分支Svn代码 1. svnmerge-rM:N/trunksvn merge -r M:N /trunk假设/trunk是主干的 URL，当前目录为分支的工作副本。该命令同步主干的最新修改到当前工作副本，用于使分支跟主干保持同步。SVN 会通过 svn:mergeinfo 属性来记录当前工作副本已经合并过的版本号，然后在每次合并时选择合适的(eligible)版本进行合并。当然，也可以自己手动指定合并版本M到N的修改。2、从分支到主干Svn代码 1. svnmerge-reintegrate/branches/quotasvn merge -reintegrate /branches/quota假设/branches/quota是分支的 URL，当前目录为主干的工作副本。该命令将分支的最新版本(HEAD)跟主干的最新版本进行比较，将差异实施到当前工作副本，用于将在分支上完成的工作合并回主干。分支使用 -reintegrate 合并回主干后，如果继续在该分支上开发，当需要同步主干的修改到分支过来时，默认会包括之前 reintegrate 的修改，而这些修改已经在分支上做过了，所以这样往往会导致冲突。这也是前面“最佳实践”中最后一个建议的一个原因。当然，想要使这个分支继续可用也是可以的，这就需要使用下面这第三种合并。3、仅记录的合并Svn代码 1. svnmerge-c25-record-only/trunksvn merge -c 25 -record-only /trunk假设当前目录为分支的工作副本，该命令将主干的版本25标记为已合并到当前工作副本，但并不会进行实质性的合并，这样下次合并主干到分支时，该版本的修改就会被跳过，避免修改被重复实施导致的冲突。其实这种合并就是改一下 svn:mergeinfo 而已，但直接修改太危险了，所以弄了这样一个所谓合并来规范操作。在 Eclipse 中进行合并操作Subclipse在 Eclipse 中有两个比较流行的 SVN 插件：Subclipse 和 Subversive，关于两者的讨论有很多，例如这里 。本文只介绍 Subclipse。上图是 Subclipse 进行合并操作时的界面，该图所对应的操作是：将 trunk 上版本 8 至今的修改同步到工作副本 pearbranch，也就是分支 branches/quake。这里可以发现几个问题： 不能进行自动合并，必须手工指定版本号。 不能进行仅记录的合并 不能直接进行 -reintegrate 的合并 CollabNet Merge Client上述 Subclipse 的不足，应该是因为 Subclipse 默认的合并实现是基于 SVN 1.4 之前的，那时还没有 svn:mergeinfo、-reintegrate 和 -record-only 呢。要支持这些 1.5 的新特性，可以安装 CollabNet Merge Client。CollabNet Merge Client 是 Subclipse 的一个可选功能，其实就是一个增强的、支持新特性的合并实现，如上图所示，它的优点有： 支持合并信息自动跟踪和自动合并 支持 -reintegrate 和 -record-only 合并前能对工作副本进行检查 什么时候应该使用分支呢？例如你接到了一个任务，完成这个任务需要三四个人的合作，你们之间需要共享资源，那们就可以创建一个专为这次任务的分支，参与此次任务的人员则在分支上做开发，等完成之后再合并到主线上，才不会出现将实现了一半的不完成功能也提交到主线上，影响主线的正常工作。又或者自己需要一个较长的开发周期来完成任务