工程師a修改了a.txt的第一行，提交了。
工程師b也修改了a.txt的第一行，然後執行svn up，這時svn提示了：（以下，你開始扮演工程師b的角色了）
$ svn up
在 「a.txt」 中發現衝突。
選擇: (p) 推遲，(df) 顯示全部差異，(e) 編輯,
(mc) 我的版本, (tc) 他人的版本,
(s) 顯示全部選項:
我一般選擇p（推遲），即引入衝突到本地，不過不會影響到svn伺服器端，可以放心。
ok，開始解決衝突了。
這時，會生成幾個檔案：
a.txt a.txt.mine a.txt.r6328 a.txt.r6336
其中a.txt中包含了工程師a、b的所有修改，以<<<<<<<、*****==、>>>>>>>分隔。
a.txt.mine是工程師b的修改，也就是未update前的a.txt。
a.txt.r6328 是工程師a提交前的版本，即未導致衝突的版本。
a.txt.r6336是工程師a提交後的版本，即導致衝突的版本。
一般，檢視a.txt就可以看到衝突的詳情了：
[yicheng@chengyi svntest]$ cat a.txt
<<<<<<< .mine
i also modify ,agndagnagasdg;
*****==
i modify this line;
>>>>>>> .r6336
以上，<<<<<<< .mine和*****==之間是工程師b（當前的「你」）修改的內容，*****==與》 .r6336之間是工程師a修改的內容。這時，最好的辦法是，叫上工程師a，你們一起確定這些修改是否都需要，是否相互相容，然後留下需要的部分，刪 除<<<<<<< .mine、*****==和》 .r6336。
然後，測試，測試！確定沒問題之後，就可以告訴svn，你解決衝突了：
svn resolve –accept working a.txt (該命令會刪除a.txt.mine a.txt.r6328 a.txt.r6336）
svn ci -m 』some comment』 a.txt
這裡需要注意的是，a.txt.mine a.txt.r6328 a.txt.r6336這幾個檔案的存在代表著有衝突產生。如果不解決衝突，就手工刪除它們，svn伺服器也會很傻的認為你解決了衝突，允許你繼續之後 的工作。但是，衝突依舊存在，你的a.txt中不但有別人的修改，還有那些討厭的<=>符號。
在衝突未解決前，試圖提交**是肯定會失敗的：
$ svn ci -m 」
svn: 提交失敗(細節如下):
svn: 提交終止: 「/path/to/svntest/a.txt」 處於衝突狀態
在使用svn update 的時候，會出現如下一些資訊：
$ svn update
u install
g readme
c bar.c
updated to revision 46.
那麼，u 開頭的資訊提示你，這個檔案在你本地沒有修改過，檔案已經根據版本庫的新版本更新了。g 開頭的資訊提示你，這個檔案在你本地已經修改過，但是和版本庫中對應的版本並沒有衝突的地方，svn已經合併更新了。而c 開頭的資訊提示你，這個檔案有點麻煩，你在本地的修改和版本庫中的版本修改的地方重疊了，也就是說，你修改了某一行，你的同事也修改了同一行。這個就需要你自己手工去解決了。當衝突發生時，要注意到有三件事情可以幫助你解決問題。
SVN衝突解決方法
svn衝突解決方法 遇到種情況，首先，你要冷靜 我們來分析一下產生衝突額原因！模擬一下 我們將乙個名為code.txt的檔案上傳到svn服務中，內容如下 然後你的小夥伴check out下來改成了 hello world 今天是21號 接著就commit svn上的最新版本就是這個了 接著，你又ch...
SVN版本衝突解決方法
解決版本衝突的命令。在衝突解決之後，需要使用svnresolved來告訴subversion衝突解決，這樣才能提交更新。衝突發生時，subversion會在workcopy中儲存所有的目標檔案版本 上次更新版本 當前獲取的版本，即別人提交的版本 自己更新的版本 目標檔案。開發人員都知道 管理工具是開...
SVN 衝突檔案快速解決方法
精簡的美麗.現在幾乎沒有幾個寫 的人不用snv來儲存 了吧！但是，在實際操作中，多人對同一檔案讀寫造成衝突是時有發生的事。這個時候解決的方法就是開啟檔案找出衝突的地方。如果衝突的部分少，那麼很容易修改過來。如果有大量衝突的話，手工修改往往會出現錯誤。拿powerdesinger的pdm檔案來講，稍微...