多人开发时有可能遇到冲突

 

1，重名文件  提交失败。

A添加一个111.txt提交成功了。版本库可以看到。

http://s2/mw690/001NkNDIgy6DNImMnEB51&690

B计划添加111.txt，刚好和A上传的重名了。http://s7/mw690/001NkNDIgy6DNInUCh0a6&690

系统提示，操作失败。文件图标左下角显示一个“蓝色加号”。

http://s11/mw690/001NkNDIgy6DNIpvLIe4a&690

继续“提交”，依然会提示 “操作失败”。

如果“更新”会提示“冲突”警告。文件图标左下角显示黄色叹号

http://s10/mw690/001NkNDIgy6DNItbXsZa9&690

然后会发现，文件夹下多了几个“奇怪”的文件，以“111”开头。

http://s7/mw690/001NkNDIgy6DNIupZfU26&690

不用去管这个文件。解决完冲突，这些自然就没有了。

解决冲突：解决冲突通常有两种办法，一种直接在文件上改，另一种用工具（TortoiseMerge、WinMerge）。
http://s15/mw690/001NkNDIgy6DNIvOUhgae&690

解决冲突要与其它同事协商。

http://s10/mw690/001NkNDIgy6DNIwQLBD79&690

比较冲突文本 、编辑冲突如上图所示。左上角是版本库里对应文件的内容，右上角是本地冲突文件的内容，下边是合并（解决冲突）后的内容。　红色部分表示是冲突的内容，要对这部分内容进行修改。

 

合并好文本后，将文件改为“已解决的”

http://s4/mw690/001NkNDIgy6DNIy3AJld3&690
http://s4/mw690/001NkNDIgy6DNIzh8mT93&690

然后会发现刚才那几个以“111”开头的奇怪文件不见了。

文件图标左下角由“黄色叹号”变为“红色叹号”。

http://s1/mw690/001NkNDIgy6DNIACIak80&690

到此为止，冲突完全解决，可以正常提交（commit）。

http://s1/mw690/001NkNDIgy6DNIBIVMsd0&690
http://s7/mw690/001NkNDIgy6DNICH4sS56&690

2，重名文件 更新时出现冲突。

开发人员A  已提交222.txt。

http://s6/mw690/001NkNDIgy6DNIDHbpPc5&690

开发人员B 本地相关文件夹下也有222.txt。

该文件是他刚增加的，无版本信息。222.txt图标左下角是个蓝色的问号。

http://s12/mw690/001NkNDIgy6DNIEPqkP9b&690

在这种情形点“更新”

http://s5/mw690/001NkNDIgy6DNIFMrpqe4&690

“更新”会显示成功，但是可以看到提示“已合并”。程序自动执行了“合并”操作。其实该操作并没有真正执行。222.txt文件里的内容还是开发人员B编辑的文本。

http://s15/mw690/001NkNDIgy6DNIGP3Ns4e&690

文件夹图标左下角显示一个红色叹号，已提醒当前操作人员。

进去后可以见到 222.txt文件图标也有个红色叹号。

http://s8/mw690/001NkNDIgy6DNIHM1nN37&690
 这时需要和其他人员商议，如何修改冲突。

http://s4/mw690/001NkNDIgy6DNIIWPu343&690

该情况下没有“编辑冲突”（上图所示），但有“更新至版本”和“svn还原”可以还原成服务器版本。

http://s11/mw690/001NkNDIgy6DNIKvS4O2a&690

或者手工编辑222.txt后，再次提交。

http://s8/mw690/001NkNDIgy6DNILGF1Be7&690

SVN版本冲突解决详解

 

版本冲突原因：

假设A、B两个用户都在版本号为100的时候，更新了kingtuns.txt这个文件，A用户在修改完成之后提交kingtuns.txt到服务器，这个时候提交成功，这个时候kingtuns.txt文件的版本号已经变成101了。同时B用户在版本号为100的kingtuns.txt文件上作修改，修改完成之后提交到服务器时，由于不是在当前最新的101版本上作的修改，所以导致提交失败。

 

版本冲突现象：

冲突发生时，subversion会在当前工作目录中保存所有的目标文件版本[上次更新版本、当前获取的版本(即别人提交的版本)、自己更新的版本、目标文件]。

假设文件名是kingtuns.txt

对应的文件名分别是：

kingtuns.txt.r101

kingtuns.txt.r102

kingtuns.txt.mine

kingtuns.txt。同时在目标文件中标记来自不同用户的更改。

 

版本冲突解决：

场景：

1、现在A、B两个用户都更新kingtuns.txt文件到本地。

http://s13/mw690/001NkNDIgy6DNKs8o205c&690
2、文档中原始文件内容如下

http://s9/mw690/001NkNDIgy6DNKu3NmU18&690
3、A用户修改文件，添加内容“A用户修改内容”完成后提交到服务器

http://s9/mw690/001NkNDIgy6DNKwcUaI18&690
4、B用户修改文件，添加内容“B用户修改内容”完成后提交到服务器

http://s11/mw690/001NkNDIgy6DNKys9FU8a&690
B用户提交更新至服务器时提示如下：

http://s13/mw690/001NkNDIgy6DNKAj5TK3c&690

B用户将文件提交至服务器时，提示版本过期：首先应该从版本库更新版本，然后去解决冲突，冲突解决后要执行svn resolved（解决），然后在签入到版本库。在冲突解决之后，需要使用svn resolved（解决）来告诉subversion冲突解决，这样才能提交更新。

 

解决冲突有三种选择：

 

A、放弃自己的更新，使用svn revert（回滚），然后提交。在这种方式下不需要使用svn resolved（解决）

 

B、放弃自己的更新，使用别人的更新。使用最新获取的版本覆盖目标文件，执行resolved filename并提交(选择文件—右键—解决)。

 

C、手动解决：冲突发生时，通过和其他用户沟通之后，手动更新目标文件。然后执行resolved filename来解除冲突，最后提交。

 

解决步骤如下：

1、  在当前目录下执行“update”（更新）操作

http://s6/mw690/001NkNDIgy6DNKCdkKVa5&690

2、  在冲突的文件上（选中文件--右键菜单—TortoiseSVN—Edit conflicts（解决冲突）），出现如下窗口

 

Theirs窗口为服务器上当前最新版本

Mine窗口为本地修改后的版本

Merged窗口为合并后的文件内容显示

http://s13/mw690/001NkNDIgy6DNKDYinO9c&690

3、  如果要使用服务器版本，在Theirs窗口选中差异内容，右键，选择Use this text block（使用这段文本块）。

同理如果要使用本地版本，在协商后，在Mine窗口右键，选择Use this text block（使用这段文本块）。

http://s3/mw690/001NkNDIgy6DNKFFMY292&690

4、  修改完成后，保存kingtuns.txt文件内容。

 

5、  在B用户的冲突目录下，选中文件--右键菜单—TortoiseSVN—Resolved（解决）。会列出冲突的文件列表，如果确认已经解决，点OK。

http://s10/mw690/001NkNDIgy6DNKHjHeh39&690

6、  冲突解决

http://s10/mw690/001NkNDIgy6DNKJbL73e9&690
7、提交解决冲突后的文件。

http://s5/mw690/001NkNDIgy6DNKLiMFC34&690

如何降低冲突解决的复杂度：

1、当文档编辑完成后，尽快提交，频繁的提交/更新可以降低在冲突发生的概率，以及发生时解决冲突的复杂度。

2、在提交时，写上明确的message，方便以后查找用户更新的原因，毕竟随着时间的推移，对当初更新的原因有可能会遗忘

3、养成良好的使用习惯，使用SVN时每次都是先提交，后更新。每天早上打开后，首先要从版本库获取最新版本。每天下班前必须将已经编辑过的文档都提交到版本库。