由於SVN採用了另一種源代碼管理機制(merge模式）,而微軟採用的是傳統的(lock/unlock）機制，由於機制不同，提交方式也不同。LOCK模?
式更適合小團隊工作，誰修改，誰加鎖，提交後解鎖。MERGE模式卻是誰都可以修改，而後提交時通過比較和合並解決分歧。所以，大家要按?
如下方式更新才能正確提交。?
?? 常見情況是：假定項目名稱是FAMS。?
?? (一) 用戶張三CHECKOUT 了 FAMS的 revision 101，然後開始工作。?
?? (二）用戶李四CHECKOUT 了 FAMS的 revision 101，然後開始工作。?
?? (三) 現在李四完成了工作，進行提交，SVN 版本號變爲revision 102，一切OK.?
?? (四) 現在張三完成了工作，也要進行提交，由於其工作的基礎版本（workingbase）是revision 101,這時SVN會提示版本已過期，需要先?
更新(svn-update).但這時真正的問題就來了：?
??? 注意SVN的機制是提交時合併，如果它發現服務器上文件版本比本地文件版本新，它會自動把服務器上的文件更新到本地，如果這個文件?
李四從未改過，一切OK，更新就可以了。?
??? 但是，如果李四也對此文件比如名字叫 fillform.java做了修改, 這又分三種情況：?
???? 第一種情況：李四新增方法或內容，張三也是新增的內容，各不衝突，一切OK，SVN會自動合併。?
???? 第二種情況：李四刪除了部分代碼，但服務器上此文件（張三提交的）此部分代碼未動，而版本卻比本地新，則SVN會自動把服務器上?
此文件內容合併到本地李四的版本中，注意啊：它把李四正確的刪除工作給反覆了，這就是SVN這種增量合併機制導致的最大問題。?
??? 正確方法是： 首先拷貝此文件到另一個臨時目錄，比如D:\TEMP，然後SVN-UPDATE此文件，第三步拷貝此文件回來，由於此時工作基礎?
版本已更新至revision101，則可以正常對比，修改。最後提交即可。?
??? 第三種情況：如果SVN-UPDATE時發生了衝突（conflict），會產生三個文件：?
??? 一個是.mine 本地版本，?
??? 一個是.r101,你的工作基準版本，?
??? 一個是.r102,服務器端的最新版本。?
??? 則手工修改衝突，然後先SVN-resolved， 注意這是告訴SVN你已經解決了衝突。然後執行下一步SVN-COMMIT即提交，就可以把新代碼更?
新上去了。?
??? 怎麼樣？說的還夠清楚吧？?
??? 這時，有讀者會問，一個文件這樣可以，那整個項目怎麼辦呢？特別是我怎麼知道哪些文件改了呢？別急，這個辦法是有滴。?
??? 一種方法是利用SVN-check FOR modification .?
??? 另一種方法是利用 SVN-show log。 在彈出的項目版本列表上選擇最新的版本（注意你的工作基礎版本會用黑體列示出來）然後在右鍵?
菜單上選擇 comparing working copy 就可以找到服務器上最新版本與你本地工作版本的所有不一致的文件了。然後對這些文件逐一處理，?
提交即可。?
???? 最後，一點提醒：注意你的代碼全部提交後，一般是用SVN-CHECKOUT 重新下載一個新版本進行工作，這樣能確保代碼最新，而不是在?
原WORKING COPY上繼續工作。