我們以孟浩然的《春曉》爲例
版本庫的內容：
有一天，用戶A與B詩意大發，覺得這首詩太俗了，他們決定改寫成現代版的《春曉》，他們商量好了，A修改前兩句，B修改後兩句。他們各自回家了。
A修改了第二句，他的工作副本是這樣的：
修改完成之後，眼睛都沒有眨一下，就直接提交了。現在版本庫和A的工作副本是一致的。B在幾天之後纔想起來這件事，他不知道A已經更新了版本庫，他直接修改了後兩句，他的工作副本是這個樣子：
修改完了之後，覺得很滿意，於是想提交到版本庫中
這時B知道A已經更新了版本庫了，於是他只有先更新，得到如下結果：
看起來沒有發生什麼錯誤，更新完成之後，他就提交了，而且也沒有發生任何錯誤。那麼B的修改會不會覆蓋A的呢？畢竟B的副本在修改之前還是舊的版本。事實證明，B的修改不會覆蓋A的，因爲他們的修改沒有發生衝突。在B提交後版本庫中的內容和B的工作副本變成下面這樣：
在A用戶更新之後，他看到的就是上圖，他看到了自己和B修改的，經過兩人的努力，這首詩的第一個版本就發佈了。
這個過程看起來非常和諧，A和B雖然同時在編輯一個文檔，而且也沒有鎖的機制，竟然一點錯誤都沒有發生，看起來有點匪夷所思。其實這得益於svn的自動合併功能。
我們下面來分析一下它自動合併的過程。
我們首先看在A提交的時候，svn認爲他修改了哪些東西：
可以看出，A修改了第二行的內容。
接下來再看看B修改的東西
可以看出，他修改了第三行和第四行
svn認爲他們分別在編輯文檔的不同部分，所以沒有發生衝突
當然，上面的這個例子畢竟是被和諧過的，下面再來看一個發生衝突的例子。
在光棍節那天，單身的用戶A和B(二者皆男性)看着身邊的一對對情侶羨慕不已。他們發誓一定要找一個出色的女友，於是約定分別把對女友的要求寫下來，看看兩人的要求是否有相互補充的，然後他們又回家開始思考了。
這時版本庫中的內容是空的。
A在文本中添加了一些條件，看起來如下：
這一回A思考了一會，然後就上傳了，現在版本庫和A的工作副本是一致的。（假設本次提交將版本號從55升到56）
同前文一樣，B在修改前從來都不喜歡更新一下工作副本，他直接將文檔修改成如下這樣：
然後他就開始上傳文檔了，看起來首先會有個提示，說文件過時，需要先更新，於是他就更新了，得到如下的結果：
這就是傳說中的衝突。
按理說他們各自添加了各自的文檔，誰也沒有修改誰的，應該不會發生衝突。
我們來看一下爲什麼會發生衝突。
在A用戶提交的時候，svn認爲他修改了哪些東西：
從上面可以看出，它認爲A新增了四行文本（第一至第四行）。
在B用戶提交的時候，svn認爲他修改了哪些東西
同理，svn認爲B新增了四行文本（第一至第四行）
綜上，svn認爲他們在同時編輯第一至第四行，這樣衝突便產生了。
svn認爲他們同時在編輯文檔的某一部分，不確定該採用誰的，所以發生了衝突。
知道了爲什麼產生衝突之後，那麼剩下的就是如何解決衝突（或者叫合併衝突）
在B更新之後，在他的工作目錄裏面會看到多了一些文件，看起來如下：
下面分別看一下這些文件是什麼意思：
db.sql：很明顯，這是發生衝突的文件，上面的感嘆號表示了該文件發生衝突了。
db.sql.mine：這是工作副本的文件，就是B修改之後的內容
db.sql.r55：這是55版本的內容，即A用戶提交之前的內容
db.sql.r56：這是56版本的內容，即A用戶提交之後的內容
打開db.sql會看到如下這樣：
在上圖中，“小於號”和“大於號”之間是發生衝突的地方，中間用“等於號”隔開。
下面右鍵發生衝突的文件，選擇編輯衝突。
打開文檔比較的窗口會是下面這樣：
圖中已經簡單標明瞭含義，左邊是別人已經提交的東西，右邊是自己將要提交的東西，兩者發生了衝突，需要進行合併。合併有如下四種方式：
使用此文本塊：在選中一行或多行的時候，此操作之後會將選中的文本作爲合併的結果
使用整個文件：將選中的整個文件作爲合併的結果（這樣會覆蓋另一方的操作）
先使用“我的”文本塊：在發生衝突的行裏面，先使用“我的”，再使用其他人之前上傳的
先使用“他們的”文本塊：與上面類似，先使用其他人的，再使用“我的”。
下面我們來合併上面的這個衝突。
結合上面這個例子，B覺得A寫得很有道理，A的幾個條件需要保留，既然A先寫的，就把A的放在前面，於是在右邊的窗口裏面選中全部的內容，然後選擇“先使用’他們的’”。
操作的過程如下：
操作完成之後，界面顯示如下：
將文檔標記爲“衝突已解決”後，再來提交一下，結果如下：
沒有再提示衝突了。A再更新一下就可以看到完整的文檔了。
我們縱觀一下整個過程，除了感覺二人的要求太高了以外，對svn的合併也有了基本的認識。