一、只有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上的編譯錯誤