zoukankan      html  css  js  c++  java
  • 版本控制工具:SVN和Maven的区别

    一、只有svn的情况 

           首先考虑没有maven的情况。这样的话,项目组每个开发人员,都需要在本地check out所有的源码。

    每次提交之前,需要先更新周边工程的代码。由于工程之间是依赖的,所以很可能需要把所有的代码都更新一遍。在项目依赖混乱的情况下,就更麻烦 ,等于说,项目组成员之间的协作,是以SVN为中心的 


          这种做法的缺点在于: 

        1、开发人员本地需要有所有的代码,编译速度很慢 

        2、如果是别人负责的模块出错,会影响自己的开发。如果项目比较大的话,别人负责的模块的问题,自己实际上是解决不了的

    这种做法的优点在于: 

        1、提交之前做一次全量更新,相当于在本地做了一次全量编译,提交到SVN上基本可以保证不会出现编译错误。我称之为“悲观提交”,类似于数据库里“悲观锁” 

        2、由于本地有所有代码,所以本地构建比较不容易出错 

    二、引入maven的情况 

            maven的主要作用之一,就是对模块化开发的支持 
      
            开发人员A机器上可以只有工程A,开发人员B机器上只有工程B,其中工程B依赖工程A 

            只要工程A已经deploy到了远程仓库(私服),那么工程B就可以在本地构建,不需要有工程A的代码。也就是说,每个开发人员本地,都只需要check out自己负责的工程


    这种做法的优点在于: 

        1、每个人只有自己负责的代码,本地构建的速度快 

        2、如果其他的模块构建出错,对自己的模块不容易造成影响 

        3、职责划分清晰 

    这种做法的缺点是: 

        1、高层模块的构建,依赖于低层的模块。由于开发人员B本地只有工程B的代码,如果工程A还没有deploy到远程仓库,则工程B就无法进行本地构建 

        2、提交到SVN后,有可能造成SVN上的全量编译失败。比如A删除了一个方法,并提交到svn,但是没有deploy。那么B就会基于A模块旧的构件来进行本地构建,成功后也提交了代码。这样的话,在svn上编译就无法通过

    要避免发生以上的问题,我觉得在项目组内要遵循2个规定: 

        1、提交了代码,需要同时将模块deploy进远程仓库。以免造成远程仓库的构件与svn源代码的不一致 

        2、需要在pom里将构件更新的策略设置为always Xml代码  
                <snapshots>  
                    <enabled>true</enabled>  
                    <updatePolicy>always</updatePolicy>  
                </snapshots>  

            以上2个规定,第一个是解决提交不一致的问题,第二个是解决获取不一致的问题。目的都是为了避免构建成功,但是svn上全量编译失败的问题 

    由于是先提交,再发现是否SVN编译失败,所以我称之为“乐观提交” 


    三、比较 

            总的来说,上述两种方式的区别,关键在于:一种是本地有所有的代码;另一种是本地只有自己负责的代码 

           对于小项目来说,不存在这个问题。但是如果是比较大的项目,我认为后者是更优的,但是会引入一些额外的问题,需要项目组所有人遵循规范来避免 


    四、引入CI 


          结合使用svn和maven,如果引入CI的话,可以让这个过程更加容易 

          开发人员在本地构建成功之后,把代码提交到svn,由CI系统(比如hudson),来完成deploy的动作 

          或者,使用SCM插件,绑定到deploy阶段。在deploy成功之后,由插件完成提交svn的动作。这样也可以保证提交svn和deploy的一致性 

          如果提交之后,在svn上全量编译失败,那么CI系统也会第一时间通知相关人员



    五、总结 



    1、建议采用分模块开发的方式,每个开发人员仅check out自己负责的代码 

    2、将snapshots更新策略设置为always 

    3、用ci系统或者scm插件,保证check in和deploy的一致性 

    4、依赖ci系统,来及时发现svn上的编译错误

  • 相关阅读:
    2017-2018-1 20179215《Linux内核原理与分析》第九周作业
    2017-2018-1 20179215 速读《构建之法》
    2017-2018-1 20179215 速读《从问题到程序》
    2017-2018-1 20179215《Linux内核原理与分析》第八周作业
    2017-2018-1 20179215《Linux内核原理与分析》第七周作业
    2017-2018-1 20179215 课堂测试
    2017-2018-1 20179215《Linux内核原理与分析》第六周作业
    2017-2018-1 20179215《Linux内核原理与分析》第五周作业
    20179215 第二周课堂测试
    2017-2018-1 20179215《Linux内核原理与分析》第三周作业
  • 原文地址:https://www.cnblogs.com/h2zZhou/p/8194023.html
Copyright © 2011-2022 走看看