(摘自西西软件园,原文连接http://www.cr173.com/html/46224_1.html)html
解决版本冲突的命令。在冲突解决以后,须要使用svnresolved来告诉subversion冲突解决,这样才能提交更新。冲突发生时,subversion会在WorkCopy中保存全部的目标文件版本(上次更新版本、当前获取的版本,即别人提交的版本、本身更新的版本、目标文件。git
开发人员都知道代码管理工具是开发中一个必不可少的工具,这里也不废话详细介绍了。无论你我的喜欢git仍是svn仍是其余,但还有一大部分公司在使用svn作代码管理工具。这里详细介绍下SVN提交文件时冲突问题的解决方式。服务器
假设A、B两个用户,他们分别从svn服务器中检出了test1.txt文件,此时A、B、服务器三个地方的test1.txt的版本都是13(我测试环境的当前svn赋予的版本号)。A、B文件的内容以下图(左A右B):svn
·工具
接下来,B用户添加一句话并提交,内容以下:测试
此时B用户和服务器的test1.txt的版本都变为14,只有A用户的test1.txt的版本还为13。接下来A用户添加一句“aa”,而后提交this
因为A用户是在13版本上作的修改,而服务器已是14版本了,因此会提交失败:3d
接下来就是咱们要解决的问题了,解决方法分为如下两种方式。第一种方式:提交失败后直接选择revert,省去了解决冲突问题;第二种方式:提交失败后选择更新文件,这时会有冲突问题。详细介绍以下:excel
第一种方式:htm
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.r1三、test1.text.r14将会消失。用户A就能够顺利提交了。可是,若是test1.txt是一个非纯文本文件,好比excel,这时的test1.txt将无法手动合并了,不得不放弃本身的修改。能够在test1.txt上右键选择
消除掉test.txt.mine、test1.txt.r1三、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而后提交。
对于非纯文本文件因版本过期提交失败时,咱们只能牺牲一下本身,选择,而后更新到服务器最新版本,再修改提交
例如,若是sally修改了一个文件sandwich.txt,而harry也刚刚修改了这个文件的相同位置并提交到服务器。那么sally在作这个文件的update操做的时候会获得三个额外的文件sandwich.txt.mine、sandwich.txt.r一、sandwich.txt.r2。而且在提交的时候会遭到服务器的拒绝,由于这个文件的冲突问题尚未获得解决。要解决这个冲突,能够选择:
a.手工合并SVN冲突文件(检查和修改文件中的冲突标志)。
b.用一个临时文件(三个中的一个)覆盖你的工做文件。
c.运行svnrevert<filename>来放弃全部的修改。
一旦解决了你的冲突,须要经过命令svnresolved让subversion知道并删除三个临时文件。这时才能够提交。
下面再说说手工合并SVN冲突。开始的时候让人以为惧怕,但作一段时间以后,就以为不那么烦人了。
看看以下文本:
Mayonnaise
Lettuce
Tomato
Provolone
<<<<<<<.mine
Salami
Mortadella
Prosciutto
=======
Sauerkraut
GrilledChicken
>>>>>>>.r2
CreoleMustard一连串的大于、小于、等于号是SVN冲突标记,这些数据得所有删除才能够提交。其中,
<<<<<<<.mine
Salami
Mortadella
Prosciutto
=======是你在冲突区里面作的修改。
Sauerkraut
GrilledChicken
>>>>>>>.r2
是别人在冲突区作的修改。
在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。同时在目标文件中标记来自不一样用户的更改。
版本冲突解决:
场景:
一、如今A、B两个用户都更新kingtuns.txt文件到本地。
二、文档中原始文件内容以下:
三、A用户修改文件,添加内容“A用户修改内容”完成后提交到服务器
四、B用户修改文件,添加内容“B用户修改内容”完成后提交到服务器
B用户提交更新至服务器时提示以下:
B用户将文件提交至服务器时,提示版本过时:首先应该从版本库更新版本,而后去解决冲突,冲突解决后要执行svn resolved(解决),而后在签入到版本库。在冲突解决以后,须要使用svn resolved(解决)来告诉subversion冲突解决,这样才能提交更新。
解决冲突有三种选择:
A、放弃本身的更新,使用svn revert(回滚),而后提交。在这种方式下不须要使用svn resolved(解决)
B、放弃本身的更新,使用别人的更新。使用最新获取的版本覆盖目标文件,执行resolved filename并提交(选择文件—右键—解决)。
C、手动解决:冲突发生时,经过和其余用户沟通以后,手动更新目标文件。而后执行resolved filename来解除冲突,最后提交。
解决步骤以下:
一、 在当前目录下执行“update”(更新)操做
二、 在冲突的文件上(选中文件--右键菜单—TortoiseSVN—Edit conflicts(解决冲突)),出现以下窗口
Theirs窗口为服务器上当前最新版本
Mine窗口为本地修改后的版本
Merged窗口为合并后的文件内容显示
三、 若是要使用服务器版本,在Theirs窗口选中差别内容,右键,选择Use this text block(使用这段文本块)。
同理若是要使用本地版本,在协商后,在Mine窗口右键,选择Use this text block(使用这段文本块)。
四、 修改完成后,保存kingtuns.txt文件内容。
五、 在B用户的冲突目录下,选中文件--右键菜单—TortoiseSVN—Resolved(解决)。会列出冲突的文件列表,若是确认已经解决,点OK。
六、 冲突解决
七、提交解决冲突后的文件。
如何下降冲突解决的复杂度:
一、当文档编辑完成后,尽快提交,频繁的提交/更新能够下降在冲突发生的几率,以及发生时解决冲突的复杂度。
二、在提交时,写上明确的message,方便之后查找用户更新的缘由,毕竟随着时间的推移,对当初更新的缘由有可能会遗忘
三、养成良好的使用习惯,使用SVN时每次都是先提交,后更新。天天早上打开后,首先要从版本库获取最新版本。天天下班前必须将已经编辑过的文档都提交到版本库。