開發人員都知道代碼管理工具是開發中一個必不可少的工具，這里也不廢話詳細介紹了。不管你個人喜歡git還是svn還是其他，但還有一大部分公司在使用svn做代碼管理工具。這里詳細介紹下SVN提交文件時沖突問題的解決方式。
假設A、B兩個用戶，他們分別從svn服務器中檢出了test1.txt文件，此時A、B、服務器三個地方的test1.txt的版本都是13(我測試環境的當前svn賦予的版本號)。A、B文件的內容如下圖（左A右B）：
·
接下來，B用戶添加一句話並提交，內容如下：
此時B用戶和服務器的test1.txt的版本都變為14，只有A用戶的test1.txt的版本還為13。接下來A用戶添加一句“aa”,然后提交
由於A用戶是在13版本上做的修改，而服務器已經是14版本了，所以會提交失敗：
接下來就是我們要解決的問題了，解決方法分為以下兩種方式。第一種方式：提交失敗后直接選擇revert，省去了解決沖突問題；第二種方式：提交失敗后選擇更新文件，這時會有沖突問題。詳細介紹如下：
第一種方式：
A放棄自己修改的內容，進行Revert操作，使其test1.txt成為13版本的最初內容。然后update使其test1.txt成為14版本，再在14版本上修改提交。操作如下圖：
==》 
==>然后再修改提交
第二種方式：
因為版本過時，提交失敗后。A用戶直接選擇更新操作，結果如下圖所見
（這里聲明下，不要被文件顯示的圖標所迷惑，這是其他軟件對它做了關聯導致的，沒啥影響）
這里詳細說一下產生沖突后的這幾個文件，：
test1.txt.mine---這個文件是A用戶在13版本中做了修改要提交的文件。它的內容是：13版本內容+A用戶的修改
test1.txt.r13----這個文件是A用戶最初的13版本的test1.txt。它的內容是：13版本內容
test1.txt.r14----這個文件時svn服務器中test1.txt的最新版本，這里既是B用戶提交后的14版本。它的內容是：13版本內容+B用戶的修改
test1.txt--------由於A用戶選擇了直接更新，此文件就是svn將 最新版本14 與 A用戶的修改 合並后的文件。它的內容如下：
接下來說一下如何解決。對於源代碼文件或其他的純文本文件，我們可以將上圖的A用戶test1.txt的內容整理下，使其滿足條件，然后 選擇
，這時test.txt.mine、test1.txt.r13、test1.text.r14將會消失。用戶A就可以順利提交了。但是，如果test1.txt是一個非純文本文件，比如excel，這時的test1.txt將沒法手動合並了，不得不放棄自己的修改。可以在test1.txt上右鍵選擇
消除掉test.txt.mine、test1.txt.r13、test1.text.r14這三個文件。（點擊Resolve不會更改test1.txt以及服務器端的內容，僅僅是消除了那幾個文件。）此時的test1.txt文件是可以提交的，它對應的是服務器的最新版本，即14版本（因為這是svn將服務器最新版本14和A用戶修改內容合並后的結果）。但這是svn幫我們合並的，是不合法的文件。我們可以右鍵然后選擇
，然后test1.txt就會變成14版本，A用戶的修改沒有了，A、B、服務器的test1.txt都成為了14版本。如下圖：
接下來A用戶就可以再進行修改提交了。
總結
對於純文本文件因版本過時提交失敗的情況，我們可以選擇更新一下，然后打開”自己的修改和服務器最新版合並“后的文件（如上文發生沖突時的test1.txt文件），進行手動合並，處理好后選擇resolve然后提交。
對於非純文本文件因版本過時提交失敗時，我們只能犧牲一下自己，選擇
，然后更新到服務器最新版本，再修改提交
如果有更好的方式，歡迎分享^_^