大话svn冲突

我们以孟浩然的《春晓》为例

版本库的内容：

 

有一天，用户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的合并也有了基本的认识。