svn与maven的区别

构建工具—maven，版本控制工具—svn。

一、只有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编译失败，所以我称之为“乐观提交”

三、比较

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

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