1.SVN更新的原則是要隨時更新，隨時提交。當完成了一個小功能，能夠通過編譯並且自己測試之後，謹慎地提交。 2.如果在修改的期間別人也更改了svn的對應檔案，那麼commit就可能會失敗。如果別人和自己更改的是同一個檔案，那麼update時會自動進行合併，如果修改的是同一行，那麼合併時會產生衝突，這種情況就需要同之前的開發人員聯絡，兩個人一起協商解決衝突，解決衝突之後，需要兩人一起測試保證解決衝突之後，程式不會影響其他功能。  3.在更新時注意所更新檔案的列表，如果提交過程中產生了更新，則也是需要重新編譯並且完成自己的一些必要測試，再進行提交。這樣既能瞭解別人修改了哪些檔案，同時也能避免SVN合併錯誤導致程式碼有錯。 

每次提交的間歇儘可能地短，以幾個小時的開發工作為宜。例如在更改UI介面的時候，可以每完成一個UI介面的修改或者設計，就提交一次。在開發功能模組的時候，可以每完成一個小細節功能的測試，就提交一次，在修改bug的時候，每修改掉一個bug並且確認修改了這個bug，也就提交一次。我們提倡多提交，也就能多為程式碼新增上保險。

一般配置管理員都會將專案中一些自動生成的檔案或者與本地配置環境有關的檔案遮蔽提交（例如eclipse中的.classpath檔案等）。如果專案中沒有進行這方面的配置來強行禁止提交這樣的檔案，請自覺不要提交這樣的檔案。提交了這樣的檔案後，別人在更新後就可能與本地的環境衝突從而影響大家的工作。 

四、 不要提交不能通過編譯的程式碼
 
程式碼在提交之前，首先要確認自己能夠在本地編譯。如果在程式碼中使用了第三方類庫，要考慮到專案組成員中有些成員可能沒有安裝相應的第三方類庫。專案經理在準備專案工作區域的時候，需要考慮到這樣的情況，確保開發小組成員在簽出程式碼之後能夠在統一的環境中進行編譯。

 
五、 不要提交自己不明白的程式碼
 
程式碼在提交入SVN之後，你的程式碼將被專案成員所分享。如果提交了你不明白的程式碼，你看不懂，別人也看不懂，如果在以後出現了問題將會成為專案質量的隱患。因此在引入任何第三方程式碼之前，確保你對這個程式碼有一個很清晰的瞭解。 

六、 提前協調好專案組成員的工作計劃

七、 對提交的資訊採用明晰的標註
 
在一個專案組中使用SVN，如果提交空的標註或者不確切的標註將會讓專案組中其他的成員感到很無奈，專案經理無法很清晰的掌握工作進度，無法清晰的把握此次提交的概要資訊。在發現錯誤後也無法準確的定位引起錯誤的檔案。所以，在提交工作時，要填寫明晰的標註，能夠概要的描述所提交檔案的資訊，讓專案組其他成員在看到標註後不用詳細看程式碼就能瞭解你所做的修改。 

八、 慎用鎖定功能
 
在專案中要慎用鎖定的功能，在你鎖定了一個檔案之後別人就無法繼續修改提交該檔案，雖然可以減少衝突的發生率，但是可能會影響專案組中其他人員的工作。平時只有在編輯那些無法合併的檔案（例如圖片檔案，flash檔案等）時，才適當的採用鎖定操作。 
 
九：SVN版本衝突解決詳解:
 
A使用者修改檔案，新增內容“A使用者修改內容”完成後提交到伺服器, B使用者修改同一個檔案，新增內容“B使用者修改內容”完成後提交到伺服器。B使用者將檔案提交至伺服器時，提示版本過期：首先應該從版本庫更新版本，然後去解決衝突，衝突解決後要執行svn resolved（解決），然後在簽入到版本庫。在衝突解決之後，需要使用svn resolved（解決）來告訴subversion衝突解決，這樣才能提交更新。

 
解決衝突有三種選擇： 
 A、放棄自己的更新，使用SVN revert（回滾），然後提交。在這種方式下不需要使用SVN resolved（解決）。
 B、放棄自己的更新，使用別人的更新。使用最新獲取的版本覆蓋目標檔案，執行resolved filename並提交(選擇檔案—右鍵—解決)。
 C、手動解決：衝突發生時，通過和其他使用者溝通之後，手動更新目標檔案。然後執行resolved filename來解除衝突，最後提交。

解決步驟：update出現衝突
在衝突的檔案上（選中檔案--右鍵選單—TortoiseSVN—Edit conflicts（解決衝突））,出現三個視窗Theirs（伺服器最新版本）、Mine（本地修改後的版本）、Merged（合併後的檔案內容顯示）

如果需要使用哪個版本，則在視窗上右鍵，選擇Use this textblock（使用這段文字塊）
修改完成後，儲存檔案
在B使用者的衝突目錄下，選中檔案--右鍵選單—TortoiseSVN—Resolved（解決）
提交解決衝突後的檔案。