首页 > 代码库 > SVN的使用,合并、冲突详解

SVN的使用,合并、冲突详解

前言:

  作为团队开发,SVN这样的版本控制工具势必是不可少的,前些日子,因为同事对SVN的使用不规范,导致了很多不必要的麻烦,然后我在QQ空间里吐槽了下,还引发了好多人的争论,不乏技术大牛也说出了自己的观点“规则优于配置”,不过作为使用者,弄清楚各种情景的原理还是很有必要的,这样利于自己利于他人。

 

情景一:单人操作文件

  示意图:

              

  第一个故事是这样的:

   靠谱哥想开个店子,迎娶白富美,走上人生巅峰!于是他动手了(比你强哦,好歹他行动了,哈哈)

   1.首先靠谱哥,他准备些资料,如上图在SVN上做了配置,文件基础版本为:V01.properties.

       2.靠谱哥后来想修改下配置文件,想增加一些内容所以他做了如下操作

      Step1:从SVN上取到基础版本V01.properties到本地;

      Step2:在本地基于V01.properties修改资料,修改完保存到本地,本地命名为:K02.V01.properties。(SVN则认为这将是V01.properties升级版,在本地叫K02.V01.properties,其中K=kaopu(靠谱),02=01的下个版本V01=基于V01版本修改而来)

      Step3:靠谱哥先update一下,未发现SVN上比本地的基础版本V01.properties更新的版本,所以SVN不用处理合并;

      Step4:commit资料,SVN在库上形成新的正式版本:V02.properties.

  3.靠谱成功完成了一次资料修改

    第一个故事描述了一次完整的SVN从  下载基础版本-->本地基于基础版本修改文件-->提交前检查SVN库上是否有新版本-->提交修改的文件,并在SVN库生成正式新版本。

情景二:两人操作同一文件

  示意图:

      

 

  第二个故事是这样的:

  靠谱哥想开个店子,迎娶白富美,走上人生巅峰!他一个人干觉得没意思,所以叫来了呆逼朋友哉哥来一起合作(靠谱还真是呆逼,自己要亏就算了,还拖基友下水,不靠谱)

      Step0:时空倒转,反正就是回到了SVN库上只有一个版本的时候,如上图:靠谱准备好了一些资料(怎么这么奇怪的资料,嘻嘻不告诉你们);

  靠谱想:“恩,这一次要设计个牛B点的URL,URL就是统一资源定位,很重要的,不能和上次一样,嗯?我为什么要说上一次,不是时空倒转了么,嗯,不管了(多傻逼的靠谱)”

  话不多少,靠谱哥操作(历史总是惊人的相,丫的操作居然又来一次):

      Step1:从SVN上取到基础版本V01.properties到本地;

      Step2:在本地基于V01.properties修改资料,修改完保存到本地,命名为:K02.V01.properties。

      Step3:靠谱哥先update一下,未发现SVN上比本地的基础版本V01.properties更新的版本,所以SVN不用处理合并;

      Step4:commit资料,SVN在库上形成新的正式版本V02.properties.

      哉哥也是个呆逼,上班一天回来累死累活,看片的时间都不够,居然最后还是答应了靠谱哥一起弄什么破店子。

      哉哥哉时空倒转后的第一时间就检查了SVN库(这特么就是职业病),好歹这也是目前唯一的资产了,结果看到基础版本里的店子居然是靠谱哥,哉哥大怒,于是一气呵成

  如下操作:

      Step1:从SVN上取到基础版本V01.properties到本地;

       Step2:在本地基于V01.properties修改资料,修改完保存到本地,命名为:Z02.V01.properties;

       Step3:哉哥先update一下,居然发现SVN上存了在比本地的基础版本V01.properties更新的版本V02.properties,所以SVN需要做点什么;

SVN的思考:哉哥基于V01.properties修改是不合理的,哉哥应该基于V02.properties来修改,但是他都已经修改完了,看来只有我来帮他合并了

第一行:没有问题,大家都没改;

第二行:靠谱哥没改,那就按哉哥的来改吧;

第三行:哉哥都不知道有第三行的存在,那我就给他加上吧;

改完了,保存在哉哥本地为Z03.V02.properties

 

      Step4:commit资料,SVN把哉哥本地的Z03.V02.properties提交到SVN库上形成新的正式版本V03.properties(),修改成功;

第二个故事讲完了,靠谱哥和哉哥两个人很默契的完成了一次对同一个文件的修改;

情景三:两人同时操作一个文件冲突

  示意图:

      

第三个故事是这样的:

  靠谱哥想开个店子,迎娶白富美,走上人生巅峰!他觉得两个人干钱不够,于是又把喜妹拖下了水。

    Step0:时空倒转,反正就是再次回到了SVN库上只有一个版本的时候,如上图:靠谱准备好了一些资料;

  哉哥还是想当店长,结果喜妹居然也有同样的想法

  哉哥操作如下:

    Step1:从SVN上取到基础版本V01.properties到本地;

     Step2:在本地基于V01.properties修改资料,修改完保存到本地,命名为:Z02.V01.properties。

     Step3:哉哥先update一下,SVN上的最佳版本依然V01.propertie,所以SVN不需要做点什么;

     Step4:commit资料,SVN把哉哥本地的Z02.V01.properties提交到SVN库上形成新的正式版本V02.properties(),修改成功

  喜妹操作如下:

    Step1:从SVN上取到基础版本V01.properties到本地;

    Step2:在本地基于V01.properties修改资料,修改完保存到本地,命名为:X02.V01.properties;

    Step3:喜妹先update一下,发现SVN的最佳版本不再是V01.properties而是V02.properties,所以SVN需要做点什么

SVN又开始思考:喜妹基于V01.properties修改是不合理的,喜妹应该基于V02.properties来修改,但是他都已经修改完了,看来只有我来帮他合并了

第一行:没有问题,大家都没改;

第二行:哉哥居然改了(店长从 靠谱哥 --> 哉哥),喜妹也改了(店长从 靠谱哥--> 喜妹);

完了完了,到底怎么改,前任店长到底要把店铺钥匙交给谁????好把,看你们干的好事儿,做为SVN我也不管了。

 

    Step4:SVN给出了冲突的提示

 

  第三个故事讲完了,故事里哉哥得知上一任店长是靠谱哥,并要求做下一任店长,同事喜妹也取到了基础版本,得知了上一任店长是靠谱哥,同样要求做下一任店长。结果两个人打起来了吧。SVN表示很为难,其实上一任店长靠谱哥也很为难;

  总结第三个故事:其实哉哥和喜妹同事获取到了上一任店长的信息,可惜哉哥有过第二个故事的经验(不是说好了时空倒转的么,毛的经验可谈啊...)及时修改了资料并及时提交,正常上位!喜妹还在基础版本上做修改,却不知道哉哥早就上位了,导致让太监(SVN)很为难,只能告诉你冲突咯,之前的修改算是白费了。当然喜妹修改前获取到的就是最新版本,只可惜手脚慢,被人先上了位,改了朝换了代,这个时候喜妹再拿着前朝的圣旨来上位,大家是不承认的,不过大家都是有素质的人,可不能直接霸蛮提交,这样哉哥上位的历史就被掩埋了。喜妹如果还想上位,就得先和现任店长商量好,如果哉哥同意了,喜妹就可以上位了。

 

情景四:故事好复杂...

  示意图:

    

 

听了这么多故事,最后这个故事就留给各位看官自己去讲吧。

 

第一次写博文总结

  文章有点乱,情节也很跳跃,道在于行,亲行之后,方才能得道,请轻点拍砖。下次要写得思路清晰些,欲知靠谱哥、哉哥、喜妹的后续故事,下回再解。

 

SVN的使用,合并、冲突详解