構建工具—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編譯失敗，所以我稱之爲“樂觀提交”
三、比較
總的來說，上述兩種方式的區別，關鍵在於：一種是本地有所有的代碼；另一種是本地只有自己負責的代碼
對於小項目來說，不存在這個問題。但是如果是比較大的項目，我認爲後者是更優的，但是會引入一些額外的問題，需要項目組所有人遵循規範來避免
四、引入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上的編譯錯誤