SVN出现叹号文件冲突解决办法
此方法是我在网上看到的,当时自己也遇到SVN文件冲突,看了后感觉还不错 ,所以收藏一下与大家分享
如下:
解决版本冲突的命令。在冲突解决之后,需要使用svn resolved来告诉subversion冲突解决,这样才能提交更新。冲突发生时,subversion会在Work Copy中保存所有的目标文件版本(上次更新版本、当前获取的版本,即别人提交的版本、自己更新的版本、目标文件。假设文件名是sandwich.txt,对应的文件名分别是:sandwich.txt.r1、sandwich.txt.r2、sandwich.txt.mine、sandwich.txt)。同时在目标文件中标记来自不同用户的更改。
解决冲突的办法:
- 手动解决:冲突发生时,通过和其他用户沟通之后,手动更新目标文件。然后执行svn resolved filename来解除冲突,最后提交。
- 放弃自己的更新,使用别人的更新。使用最新获取的版本覆盖目标文件,执行svn resolved filename并提交。
- 放弃自己的更新,使用svn revert,然后提交。在这种方式下不需要使用svn resolved。
对于svn resolved命令需要非常小心,必须是非常确定冲突已经解决才能使用。否则,会导致Subversion以为冲突解决,而使代码库不正确。
解决冲突详细文档: http://svnbook.subversion.org.cn/1.2/svn.tour.cycle.html#svn.tour.cycle.resolve
解决冲突(合并别人的修改)
我们可以使用svn status -u来预测冲突,当你运行svn update一些有趣的事情发生了:
$ svn update
U INSTALL
G README
C bar.c
Updated to revision 46.
U和G没必要关心,文件干净的接受了版本库的变化,文件标示为U表明本地没有修改,文件已经根据版本库更新。G标示合并,标示本地已经修改过,与版本库没有重迭的地方,已经合并。
但是C表示冲突,说明服务器上的改动同你的改动冲突了,你需要自己手工去解决。
当冲突发生了,有三件事可以帮助你注意到这种情况和解决问题:
Subversion打印C标记,并且标记这个文件已冲突。
如果Subversion认为这个文件是可合并的,它会置入冲突标记—特殊的横线分开冲突的“两面”—在文件里可视化的描述重叠的部分(Subversion使用svn:mime-type属性来决定一个文件是否可以使用上下文的,以行为基础合并,更多信息可以看“svn:mime-type”一节)。
对于每一个冲突的文件,Subversion放置三个额外的未版本化文件到你的工作拷贝:
filename.mine
你更新前的文件,没有冲突标志,只是你最新更改的内容。(如果Subversion认为这个文件不可以合并,.mine文件不会创建,因为它和工作文件相同。)
filename.rOLDREV
这是你的做更新操作以前的BASE版本文件,就是你在上次更新之后未作更改的版本。
filename.rNEWREV
这是你的Subversion客户端从服务器刚刚收到的版本,这个文件对应版本库的HEAD版本。
这里OLDREV是你的.svn目录中的修订版本号,NEWREV是版本库中HEAD的版本号。
举一个例子,Sally修改了sandwich.txt,Harry刚刚改变了他的本地拷贝中的这个文件并且提交到服务器,Sally在提交之前更新它的工作拷贝得到了冲突:
$ svn update
C sandwich.txt
Updated to revision 2.
$ ls -1
sandwich.txt
sandwich.txt.mine
sandwich.txt.r1
sandwich.txt.r2
在这种情况下,Subversion不会允许你提交sandwich.txt,直到你的三个临时文件被删掉。
$ svn commit --message "Add a few more things"
svn: Commit failed (details follow):
svn: Aborting commit: '/home/sally/svn-work/sandwich.txt' remains in conflict
如果你遇到冲突,三件事你可以选择:
“手动”合并冲突文本(检查和修改文件中的冲突标志)。
用某一个临时文件覆盖你的工作文件。
运行svn revert <filename>来放弃所有的修改。
一旦你解决了冲突,你需要通过命令svn resolved让Subversion知道,这样就会删除三个临时文件,Subversion就不会认为这个文件是在冲突状态了。[5]
$ svn resolved sandwich.txt
Resolved conflicted state of 'sandwich.txt'
手工合并冲突
第一次尝试解决冲突让人感觉很害怕,但经过一点训练,它简单的像是骑着车子下坡。
这里一个简单的例子,由于不良的交流,你和同事Sally,同时编辑了sandwich.txt。Sally提交了修改,当你准备更新你的版本,冲突发生了,我们不得不去修改sandwich.txt来解决这个问题。首先,看一下这个文件:
$ cat sandwich.txt
Top piece of bread
Mayonnaise
Lettuce
Tomato
Provolone
<<<<<<< .mine
Salami
Mortadella
Prosciutto
=======
Sauerkraut
Grilled Chicken
>>>>>>> .r2
Creole Mustard
Bottom piece of bread
小于号、等于号和大于号串是冲突标记,并不是冲突的数据,你一定要确定这些内容在下次提交之前得到删除,前两组标志中间的内容是你在冲突区所做的修改:
<<<<<<< .mine
Salami
Mortadella
Prosciutto
=======
后两组之间的是Sally提交的修改冲突:
=======
Sauerkraut
Grilled Chicken
>>>>>>> .r2
通常你并不希望只是删除冲突标志和Sally的修改—当她收到三明治时,会非常的吃惊。所以你应该走到她的办公室或是拿起电话告诉Sally,你没办法从从意大利熟食店得到想要的泡菜。[6]一旦你们确认了提交内容后,修改文件并且删除冲突标志。
Top piece of bread
Mayonnaise
Lettuce
Tomato
Provolone
Salami
Mortadella
Prosciutto
Creole Mustard
Bottom piece of bread
现在运行svn resolved,你已经准备好提交了:
$ svn resolved sandwich.txt
$ svn commit -m "Go ahead and use my sandwich, discarding Sally's edits."
记住,如果你修改冲突时感到混乱,你可以参考subversion生成的三个文件—包括你未作更新的文件。你也可以使用第三方的合并工具检验这三个文件。
拷贝覆盖你的工作文件
如果你只是希望取消你的修改,你可以仅仅拷贝Subversion为你生成的文件替换你的工作拷贝:
$ svn update
C sandwich.txt
Updated to revision 2.
$ ls sandwich.*
sandwich.txt sandwich.txt.mine sandwich.txt.r2 sandwich.txt.r1
$ cp sandwich.txt.r2 sandwich.txt
$ svn resolved sandwich.txt
下注:使用svn revert
如果你得到冲突,经过检查你决定取消自己的修改并且重新编辑,你可以恢复你的修改:
$ svn revert sandwich.txt
Reverted 'sandwich.txt'
$ ls sandwich.*
sandwich.txt
注意,当你恢复一个冲突的文件时,不需要再运行svn resolved。
现在我们准备好提交修改了,注意svn resolved不像我们本章学过的其他命令一样需要参数,在任何你认为解决了冲突的时候,只需要小心运行svn resolved,—一旦删除了临时文件,Subversion会让你提交这文件,即使文件中还存在冲突标记。
提交你得修改
最后!你的修改结束了,你合并了服务器上所有的修改,你准备好提交修改到版本库。
svn commit命令发送所有的修改到版本库,当你提交修改时,你需要提供一些描述修改的日志信息,你的信息会附到这个修订版本上,如果信息很简短,你可以在命令行中使用--message(-m)选项:
$ svn commit --message "Corrected number of cheese slices."
Sending sandwich.txt
Transmitting file data .
Committed revision 3.
然而,如果你把写日志信息当作工作的一部分,你也许会希望通过告诉Subversion一个文件名得到日志信息,使用--file选项:
$ svn commit --file logmsg
Sending sandwich.txt
Transmitting file data .
Committed revision 4.
如果你没有指定--message或者--file选项,Subversion会自动地启动你最喜欢的编辑器(见“config”一节的editor-cmd部分)来编辑日志信息。
提示
如果你使用编辑器撰写日志信息时希望取消提交,你可以直接关掉编辑器,不要保存,如果你已经做过保存,只要简单的删掉所有的文本并再次保存。
$ svn commit
Waiting for Emacs...Done
Log message unchanged or not specified
a)bort, c)ontinue, e)dit
a
$
版本库不知道也不关心你的修改作为一个整体是否有意义,它只检查是否有其他人修改了同一个文件,如果别人已经这样做了,你的整个提交会失败,并且提示你一个或多个文件已经过时了:
$ svn commit --message "Add another rule"
Sending rules.txt
svn: Commit failed (details follow):
svn: Out of date: 'rules.txt' in transaction 'g'
此刻,你需要运行svn update来处理所有的合并和冲突,然后再尝试提交。
我们已经覆盖了Subversion基本的工作周期,还有许多其它特性可以管理你得版本库和工作拷贝,但是只使用前面介绍的命令你就可以很轻松的工作了。
[3] 当然没有任何东西是在版本库里被删除了—只是在版本库的HEAD里消失了,你可以通过检出(或者更新你的工作拷贝)你做出删除操作的前一个修订版本来找回所有的东西。
[4] Subversion使用内置区别引擎,缺省情况下输出为统一区别格式。如果你期望不同的输出格式,你可以使用--diff-cmd指定外置的区别程序,并且通过--extensions传递其他参数,举个例子,察看本地文件foo.c的区别,同时忽略空格修改,你可以运行svn diff --diff-cmd /usr/bin/diff --extensions '-bc' foo.c。
[5] 你也可以手工的删除这三个临时文件,但是当Subversion会给你做时你会自己去做吗?我们是这样想的。
[6] 如果你向他们询问,他们非常有理由把你带到城外的铁轨上。
如何降低冲突解决的复杂度:
- 当工作完成之后(即编写完程序,单元测试通过)尽快的提交,频繁的提交/更新可以降低在冲突发生的概率,以及发生时解决冲突的复杂度。
- 如果冲突频繁发生,就有必要找出原因了。
- 在提交时,书写明确的message。方便以后的查找更新的原因,毕竟随着时光流逝,记忆也会变得模糊。