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仓库中，只要仓库存储在电脑上的磁盘没被删除，那中间所有版本的代码均是可以找回的。我们在合作开发过程中，难免会遇到上述一些问题，利用一些智能的管理工具可解决代码冲突、版本冲突等问题，也是工具创建者的智慧所在。