目前项目组在开发一个项目，由多个子模块构成，构建工具是maven，版本控制工具是svn。本文想对如何结合使用maven和svn提出一点初步的想法 数据库
1、只有svn的状况
首先考虑没有maven的状况。这样的话，项目组每一个开发人员，都须要在本地check out全部的源码。
每次提交以前，须要先更新周边工程的代码。因为工程之间是依赖的，因此极可能须要把全部的代码都更新一遍。在项目依赖混乱的状况下，就更麻烦 ，等于说，项目组成员之间的协做，是以SVN为中心的
这种作法的缺点在于：
一、开发人员本地须要有全部的代码，编译速度很慢
二、若是是别人负责的模块出错，会影响本身的开发。若是项目比较大的话，别人负责的模块的问题，本身其实是解决不了的
这种作法的优势在于：
一、提交以前作一次全量更新，至关于在本地作了一次全量编译，提交到SVN上基本能够保证不会出现编译错误。我称之为“悲观提交”，相似于数据库里“悲观锁”
二、因为本地有全部代码，因此本地构建比较不容易出错
2、引入maven的状况
maven的主要做用之一，就是对模块化开发的支持
开发人员A机器上能够只有工程A，开发人员B机器上只有工程B，其中工程B依赖工程A
只要工程A已经deploy到了远程仓库（私服），那么工程B就能够在本地构建，不须要有工程A的代码。也就是说，每一个开发人员本地，都只须要check out本身负责的工程
这种作法的优势在于：
一、每一个人只有本身负责的代码，本地构建的速度快
二、若是其余的模块构建出错，对本身的模块不容易形成影响
三、职责划分清晰
这种作法的缺点是：
一、高层模块的构建，依赖于低层的模块。因为开发人员B本地只有工程B的代码，若是工程A尚未deploy到远程仓库，则工程B就没法进行本地构建
二、提交到SVN后，有可能形成SVN上的全量编译失败。好比A删除了一个方法，并提交到svn，可是没有deploy。那么B就会基于A模块旧的构件来进行本地构建，成功后也提交了代码。这样的话，在svn上编译就没法经过
要避免发生以上的问题，我以为在项目组内要遵循2个规定：
一、提交了代码，须要同时将模块deploy进远程仓库。以避免形成远程仓库的构件与svn源代码的不一致
二、须要在pom里将构件更新的策略设置为always Xml代码
<snapshots>
<enabled>true</enabled>
<updatePolicy>always</updatePolicy>
</snapshots>
以上2个规定，第一个是解决提交不一致的问题，第二个是解决获取不一致的问题。目的都是为了不构建成功，可是svn上全量编译失败的问题
因为是先提交，再发现是否SVN编译失败，因此我称之为“乐观提交”
3、比较
总的来讲，上述两种方式的区别，关键在于：一种是本地有全部的代码；另外一种是本地只有本身负责的代码
对于小项目来讲，不存在这个问题。可是若是是比较大的项目，我认为后者是更优的，可是会引入一些额外的问题，须要项目组全部人遵循规范来避免
4、引入CI
结合使用svn和maven，若是引入CI的话，可让这个过程更加容易
开发人员在本地构建成功以后，把代码提交到svn，由CI系统（好比hudson），来完成deploy的动做
或者，使用SCM插件，绑定到deploy阶段。在deploy成功以后，由插件完成提交svn的动做。这样也能够保证提交svn和deploy的一致性
若是提交以后，在svn上全量编译失败，那么CI系统也会第一时间通知相关人员
5、总结
总的来讲，我认为有如下几点：
一、建议采用分模块开发的方式，每一个开发人员仅check out本身负责的代码
二、将snapshots更新策略设置为always 解决获取不一致
三、用ci系统或者scm插件，保证check in和deploy的一致性
四、依赖ci系统，来及时发现svn上的编译错误maven