版權聲明：本文為博主原創文章，未經博主允許不得轉載。 https://blog.csdn.net/Rundy_Deng/article/details/80338093
也會讓我們百思不得其解，甚至耽誤項目進度，浪費程序員的心血和結晶。
下面就我們在外事項目中使用SVN的經驗簡單做個說明。
如何正確提交代碼？
可能很多人用過微軟的VISUAL SOURCESAFE 或者 Team Foundation Server，就認為那還不簡單，checkout/checkin 不就完了嗎。孰不知
由於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上繼續工作。
下面就我們在外事項目中使用SVN的經驗簡單做個說明。
如何正確提交代碼？
可能很多人用過微軟的VISUAL SOURCESAFE 或者 Team Foundation Server，就認為那還不簡單，checkout/checkin 不就完了嗎。孰不知
由於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上繼續工作。