SVN的代碼正確提交方法(轉)

原文參考:http://blog.sina.com.cn/s/blog_5920510a010128ax.html

 

  想必你們如今都比較喜歡使用svn(subversion)完成代碼管理了，由於它的開源，輕巧，易用。可是這樣一個寶貝若是不知道其正確的用法，也會讓咱們百思不得其解，甚至耽誤項目進度，浪費程序員的心血和結晶。
   下面就咱們在外事項目中使用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上繼續工做。