培训SVN分支合并tag

1/26一、SVN培训-重点分支、合并、tagVisualSVNServerTortoiseSVNCornerStone1.名称解释SVN术语，Clearcase（UCM&Base）术语repositoryvob存储库配置库trunkbasemainlineintegration-stream主干主线集成流branchdevelopment-stream分支开发流tagbaselinelablesnapshot标签基线快照workcopyview工作副本视图本地工作空间意义是人赋予的2/262.SVN工作方式3/264/265/266/26二、Branch&MergingThenextpointtonoteisthatmergingalwaystakesplacewithinaworkingcopy.Ifyouwanttomergechangesintoabranch,youhavetohaveaworkingcopyforthatbranchcheckedout,andinvokethemergewizardfromthatworkingcopyusingTortoiseSVN→Merge....SVN可以为一个版本库中的内容(主干)建立一个分支.分支和主干完全独立，就相当于把代码再复制一份，重新添加到版本库中。但SVN提供另一个功能，就是把主干做出的修改合并到分支中，以及把分支修改的内容合并到主干中。示例:基于TortoiseSVN1.建一个分支.7/268/26建立时要注意：1.当前复制源,即专业术语中的主干(truck)2.分支存放的位置.当然，分支也是在SVN版本库中.3.写上日志.这个大家应该懂的.4.如果目录路径不存在，勾选“Createintermediatefolders”，否则确认后会报错。Switch选项建议为空。switch含义：是否把主干的路径切换到分支.如果勾选了，建立分支后，在主干里做出的修改并提交后，更新会提交到分支上。主干的版本源内容不会变。这时我们看一下trunk目录的属性，可以看到它的路径已经变成:/calc/branches/my-calc-branch了。9/26为了避免产生困惑。以及失误。在建立的时候不要勾上切换到分支的选项。如果勾上了，我们还是切换回去:10/26注意:1.主干的目录2.版本库源路径这时你便可以在/calc/branches/my-calc-branch分支上开发新的功能，且不会影响到其他成员开发或维护主干的内容。其他方向建分支:在Repo-Browser中：1.Ctrl+拖拽的方式；2.Copyto3.ShowLog中选择任意Reversion，右击-Branch/Tag11/262.合并主干的变更也许过了一段时间，原本的/calc/trunk主干可能已经有其他成员陆续修正了一些Bugs，但这时你的分支/calc/branches/my-calc-branch就可以直接套用主干(/calc/trunk)的更新，除了避免重复的工作外，也可以避免版本的冲突，因为多人改同样的文件可能发生冲突。经常將开发主干(/calc/trunk)的变更透过svnmerge合并至分支(/calc/branches/my-calc-branch)是一个非常好的习惯，这样才不会让你脱离主干(trunk)过久而导致将分支(/calc/branches/my-calc-branch)合并回主干(/calc/trunk)时发生许多冲突。12/26从主干(/calc/trunk)合并至分支(/calc/branches/my-calc-branch)通常选第1个，也就是[Mergearangeofrevisions]注意.我们是在分支上使用的Merge功能.因为是要在分支上应用主干的更新.13/26在Merge的窗口有以下注意事項：1.合并的来源，由于我们打算从主干(/calc/trunk)合并至分支(/calc/branches/my-calc-branch)，所以合并的來源要选/calc/trunk才对！2.合并的结果会直接与目前「工作目录」(WorkingCopy)做比对，并修改目前工作目录中的所有文件。因此建议在做合并之前可以将所有尚未commit的档案先commit到版本库，避免不必要的冲突事件发生。14/26在正式进行合并(Merge)之前，建议先执行Testmerge看看是否会发生什么事!若无异状则可直接按下[Merge]按钮进行合并动作，这时从主干(/calc/trunk)分支出来的到目前工作目录的版本就会做个比较，然后直接套用变更到你现有的文件、目录或属性里。15/26在合并之后如果没有发生冲突，不代表真的没冲突，所以必须再次对原始码做出验证后才能commit进版本库，建议可参考以下流程：1.将项目进行建置(Build)2.如果没问题再对项目进行单元测试(UnitTesting)或手动测试(ManualTesting)3.如果都没问题再commit目前合并无误的版本到版本库！16/263.合并分支到主干最后我们的my-calc-branch分支已经将新功能开发完成且测试无误，所以要将分支(/calc/branches/my-calc-branch)的最终版本合并回主干(/calc/trunk)，这时的手续如下：17/2618/26从分支(/calc/branches/my-calc-branch)合并回主干(/calc/trunk)通常选第2个，而特别选择[Reintegrateabranch]这个选项是很重要的，因为这有以下好处：1.让Subversion能知道主干(/calc/trunk)是从哪个分支、哪些版本合并进来的2.有效节省SubversionRepository(SVN储存库)的空间，因为不用重复储存分支的所有变更信息3.可以产生Revisiongraph得知项目开发的分支状况19/26一样可以先测试合并(Testmerge)再正式进行合并(Merge)20/26合并完后再将变更commit到版本库21/264.删除使用完毕的分支当分支(/calc/branches/my-calc-branch)合并回主干(/calc/trunk)并commit了之后，该分支就没用了，该分支如果未来不再更新或继续开发，Subversion也不会继续追踪这个分支的变更(因为之前已经Reintegrate过了)，建议将该分支删除。22/26三、配置管理策略演变过程见ppt关于什么时候主干和流的同步，了解配置工具特性后，根据开发情况由用户决定。四、回顾总结1.一个workcopy和它对应的流之间的同步：update从流更新到workcopy（有冲突时，编辑冲突-解决状态），编译测试没有问题之后，从workcopy提交（commite）到流。2.其实一个开发流和主干的关系，可以从宏观上理解成一个workcopy和它对应的流的关系，只不过开发流和主干之间的互动变了一个名称：从主干更新到开发流用merge（有冲突时，编辑冲突-解决状态），从开发流提交到主干也是merge。23/26从1到2就是随着开发人员的增多和项目需要的增加，而出现的配置策略的变化。对update的解读，因为workcopy刚建立的时候是从流的最新状态下载下来的（此时版本一致）；如果有其他人提交到流，此时流中有些文件的版本高于workcopy中的版本，在做update时会将流中最新的版本同步下来：1.如果新版本正是自己编辑的文件，此文件就会处于冲突状态，需要工具或手动解决；2.如果新版本与本地文件没有冲突，自动同步下流上的更新；3.如果没人有提交（workcopy和本地版本一致）update不会同步下来任何东西（相当于此时没有update）。流和流之间的merge其实和workcopy和它对应的流update的效果是一样的，都是把新的版本（新的变更）同步下来：1.新的变更与本地变更有冲突，在本地编译解决冲突；2.新变更与本地变更无冲突，同步下来新的变更，此时本地变更是（A+B两个的变更）；3.主干上没有人提交变更，同步不下来东西。常规模式：project/trunk---线上稳定最新的版本（主干可测的稳定版本，永远可以发布的）tags/btags--测试基线tags/rtags--release基线(发布基线)branches--开发空间，存放分支现在提测研发人员没有做测试版本tag，建议提测做相应的tag放在btags中，发布上线的版本做tag到rtags中。比如：Zhuoda543544545都是给测试打的版本，把基线打到btags（甚至测试人员可以用btags下面的代码自己编译出测试包）；每个测试的tag记录了这次的变更。正式上线的Zhuoda546做tag到rtags中，方便以后追溯。24/26五、SVN使用注意事项提交之前先更新1.SVN更新的原则是要随时更新，随时提交。当完成了一个小功能，能够通过编译并且自己测试之后，谨慎地提交。2.如果在修改的期间别人也更改了svn的对应文件，那么commit就可能会失败。如果别人和自己更改的是同一个文件，那么update时会自动进行合并，如果修改的是同一行，那么合并时会产生冲突，这种情况就需要同之前的开发人员联系，两个人一起协商解决冲突，解决冲突之后，需要两人一起测试保证解决冲突之后，程序不会影响其他功能。3.在更新时注意所更新文件的列表，如果提交过程中产生了更新，则也是需要重新编译并且完成自己的一些必要测试，再进行提交。这样既能了解别人修改了哪些文件，同时也能避免SVN合并错误导致代码有错。保持原子性的提交（一次提交只改一个bug）每次提交的间歇尽可能地短，以几个小时的开发工作为宜。例如在更改UI界面的时候，可以每完成一个UI界面的修改或者设计，就提交一次。在开发功能模块的时候，可以每完成一个小细节功能的测试，就提交一次，在修改bug的时候，每修改掉一个bug并且确认修改了这个bug，也就提交一次。我们提倡多提交，也就能多为代码添加上保险。对SVN提交的信息(LogMessage)采用明晰的标注在一个项目组中使用SVN，如果提交空的标注或者不确切的标注将会让项目组中其他的成员感到很无奈，项目经理无法很清晰的掌握工作进度，无法清晰的把握此次提交的概要信息。在发现错误后也无法准确的定位引起错误的文件。所以，在提交工作时，要填写明晰的标注，能够概要的描述所提交文件的信息，让项目组其他成员在看到标注后不用详细看代码就能了解你所做的修改。SVN提交时注意不要提交本地自动生成的文件一般配置管理员都会将项目中一些自动生成的文件或者与本地配置环境有关的文件屏蔽提交（例如eclipse中的.classpath文件等）。如果项目中没有进行这方面的配置来强行禁止提交这样的文件，请自觉不要提交这样的文件。提交了这样的文件后，别人在更新后就可能与本地的环境冲突从而影响大家的工作。不要提交不能通过编译的代码代码在提交之前，首先要确认自己能够在本地编译。如果在代码中使用了第三方类库，要25/26考虑到项目组成员中有些成员可能没有安装相应的第三方类库。项目经理在准备项目工作区域的时候，需要考虑到这样的情况，确保开发小组成员在签出代码之后能够在统一的环境中进行编译。不要提交自己不明白的代码代码在提交入SVN之后，你的代码将被项目成员所分享。如果提交了你不明白的代码，你看不懂，别人也看不懂，如果在以后出现了问题将会成为项目质量的隐患。因此在引入任何第三方代码之前，确保你对这个代码有一个很清晰的了解。8.7SVN提交时提前协调好项目组成员的工作计划项目经理应该合理分配工作计划。每个成员在准备开始进行某项功能的修改之前，如果有可能，先跟工作小组的成员谈谈自己的修改计划，让大家都能了解你的思想，了解你即将对软件作出的修改，这样能尽可能的减少在开发过程中可能出现的冲突，提高开发效率。同时你也能够在和成员的交流中发现自己之前设计的不足，完善你的设计。慎用锁定功能在项目中要慎用锁定的功