SVN版本控制——常见问题篇
一、多用户合作开发,提交代码修改冲突
在大项目开发中,合作开发是不可避免,多个开发者共同对一个模块进行编码,提交实属常事,那就很容易出现:AB两开发者同时对一个类进行修改,两人代码发生重叠,B手疾眼快的提交代码后,A第二天来不爽的发现"谁动了我的代码?!自己辛辛苦苦写好的逻辑,被修改的面目全非";这种情况在合作开发的过程中并不罕见。
解决方案:
AB可通过商量,利用SVN——》show log中选中某版本代码日志,右击‘revert to this revision’即可将代码版本恢复到指定版本。
二、B误删了A整模块代码
B又一次手贱,这次不是改改而已,而是将A的整个类全部删除,心急如焚的A找到了如下解决办法:
通过show log——》找到B删除A代码的log日志记录,将已删除的类另存“save reversion to”,然后再次提交即可。
三、AB同时修改一个方法,导致A提交失败,更新一堆错误
B程序猿依旧不加以注意,现在是B先对A的代码做了修改,改完了立马就提交了;不知情的A同学同样在改完代码之后,再去提交代码,则会出现文件过时,提交失败,请先更新的提示。
好吧,更新就更新吧,更新会出现两种状况,如果B只是添加代码,并未对A原本的方法进行修改,则SVN会自动将两块代码文件进行合并;但如果B修改的恰好是A的代码,甚至 AB修改的代码是同一行,那么更新便会使得A修改的代码被覆盖,同时SVN会生成类似于“》》》mine”等提示让开发者确定到底用哪行代码。这就是所谓冲突。
A提交报错:
更新后,发现某一行代码发生冲突
同时,更新后生成了其他多余代码文件
冲突的原因即在于:B修改了A的代码,并先于A进行提交,使得SVN上目前最新的版本代码与A已经发生冲突;如果B只在A文件中添加,而非对A相同的代码进行直接修改,则SVN会启动合并机制,将B修改的代码合并与A中,但如果B是直接修改A原本存在的代码,而A在不知情的情况下也进行了修改操作,便会出现A提交失败,更新后自己修改的代码也会被覆盖,此时更新下的文件就如上图,黄色感叹号表示SVN不只如何合并,并且出现了三个多余文件,含义分别如下。
解决方案一:
这时则需要AB商量,确定最终保留谁的代码。确定后,一行一行去删除SVN提示的“》》》mine”等标识。更方便简单的是,直接确定好最后保留上述三个文件中哪一个,最后删除其他,重新提交即可。或者如果同意B的代码正确,则右击123.text黄色感叹号文件,revert 即可。其他三个文件则自动消失,此时SVN上将保留B最终修改完成的代码。
解决方案二:
拒绝更新!既然更新完后一堆错误,那就不要更新了!直接将自己的代码复制一遍,同时档下SVN上最新版本代码,通过SVN对比功能,查看A自己当前代码与SVN最新版本的差异,通过将自己新增的代码粘贴到最新版本一侧,再次提交最新版本代码;这样子就等同于在最新代码基础之上进行修改,也可以解决代码提交失败,更新还出一堆错误的问题了。
对比当前代码与svn最新代码差异:
所以,利用SVN进行版本控制,只要代码从第一次执行更新、删除、提交操作到SVN上时,每一过程都记录到SVN仓库中,只要仓库存储在电脑上的磁盘没被删除,那中间所有版本的代码均是可以找回的。我们在合作开发过程中,难免会遇到上述一些问题,利用一些智能的管理工具可解决代码冲突、版本冲突等问题,也是工具创建者的智慧所在。
---------------------
作者:钟艾伶
来源:CSDN
原文:https://blog.csdn.net/Daybreak1209/article/details/50373480
版权声明:本文为博主原创文章,转载请附上博文链接!