目前項目組在開發一個項目，由多個子模塊構成，構建工具是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