也會讓我們百思不得其解，甚至耽誤專案進度，浪費程式設計師的心血和結晶。
下面就我們在外事專案中使用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.j**a做了修改, 這又分三種情況：
第一種情況：李四新增方法或內容，張三也是新增的內容，各不衝突，一切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 就可以找到伺服器上最新版本與你本地工作版本的所有不一致的檔案了。然後對這些檔案逐一處理，
提交即可。
原working copy上繼續工作。
SVN 提交小結
在我們用vs進行專案合作開發的過程中，svn的提交控制是至關重要的，由於版本衝突造成的各種麻煩咱們已經遇到的夠多了。所以，總結他們的經驗教訓，給我們也給其他人做個提醒。下面的第一部分是需要在正式開發之前需要做的，第二部分是開發的過程中需要注意的。由於編譯性的檔案 包括obj資料夾和bin資料夾 並不...
SVN提交 a檔案
使用命令列新增檔案 1.開啟終端，輸入cd，空格，然後將需要上傳的.a檔案所在的資料夾 不是.a檔案 拖拽到終端 此辦法無需輸入繁瑣的路徑，快捷方便 回車 2.之後再輸入如下命令 svn add libocmock.a，回車 3.之後會出現 a bin libocmock.a 表示新增成功，開啟ve...
SVN提交小結
目錄 一排除不必要的提交 1將編譯性的檔案排除在提交之外 11 obj資料夾 12 bin資料夾 2 將屬於每個使用者的檔案排除在提交之外 21 csprojuser 22 suo 3 排除方法 二提交的幾個原則 1先更新再生成解決方案最後提交 11 先update整個解決方案 12 然後保證在提交...