工程师B也修改了a.txt的第一行,然后执行svn up,这时SVN提示了:(以下,你开始扮演工程师B的角色了)
$ svn up
在 “a.txt” 中发现冲突。
选择: (p) 推迟,(df) 显示全部差异,(e) 编辑,
(mc) 我的版本, (tc) 他人的版本,
(s) 显示全部选项:
我一般选择p(推迟),即引入冲突到本地,不过不会影响到SVN服务器端,可以放心。
OK,开始解决冲突了。
这时,会生成几个文件:
a.txt a.txt.mine a.txt.r6328 a.txt.r6336
其中a.txt中包含了工程师A、B的所有修改,以<<<<<<<、=======、>>>>>>>分隔。
a.txt.mine是工程师B的修改,也就是未update前的a.txt。
a.txt.r6328 是工程师A提交前的版本,即未导致冲突的版本。
a.txt.r6336是工程师A提交后的版本,即导致冲突的版本。
一般,查看a.txt就可以看到冲突的详情了:
[yicheng@chengyi svntest]$ cat a.txt
<<<<<<<.mine
i also modify ,agndagnagasdg
=======
i modify this line
>>>>>>>.r6336
以上,<<<<<<<.mine和=======之间是工程师B(当前的“你”)修改的内容,=======与>>>>>>>.r6336之间是工程师A修改的内容。这时,最好的办法是,叫上工程师A,你们一起确定这些修改是否都需要,是否相互兼容,然后留下需要的部分,删 除<<<<<<<.mine、=======和>>>>>>>.r6336。
然后,测试,测试!确定没问题之后,就可以告诉SVN,你解决冲突了:
svn resolve –accept working a.txt (该命令会删除a.txt.mine a.txt.r6328 a.txt.r6336)
svn ci -m ’some comment’ a.txt
这里需要注意的是,a.txt.mine a.txt.r6328 a.txt.r6336这几个文件的存在代表着有冲突产生。如果不解决冲突,就手工删除它们,SVN服务器也会很傻的认为你解决了冲突,允许你继续之后 的工作。但是,冲突依旧存在,你的a.txt中不但有别人的修改,还有那些讨厌的<=>符号。
在冲突未解决前,试图提交代码是肯定会失败的:
$ svn ci -m ”
svn: 提交失败(细节如下):
svn: 提交终止: “/path/to/svntest/a.txt” 处于冲突状态
在使用svn update 的时候,会出现如下一些信息:
$ svn update
U INSTALL
G README
C bar.c
Updated to revision 46.
那么,U 开头的信息提示你,这个文件在你本地没有修改过,文件已经根据版本库的新版本更新了。G 开头的信息提示你,这个文件在你本地已经修改过,但是和版本库中对应的版本并没有冲突的地方,svn已经合并更新了。而C 开头的信息提示你,这个文件有点麻烦,你在本地的修改和版本库中的版本修改的地方重叠了,也就是说,你修改了某一行,你的同事也修改了同一行。这个就需要你自己手工去解决了。当冲突发生时,要注意到有三件事情可以帮助你解决问题。
在团队开发中很多情况都会出现,下面就来一个一个的讲解一下svn中的一下应用,以及遇到问题后如何解决。在Myeclipse中一定要有安装svn,可以在线安装也可以离线安装。项目一定要是在svn中检出出来的,还有就是做过修改的,不管会别人修改的还是自己修改的,这样才能看出来有没有差别,然后右击项目找打Team的与资源库同步,这样就能进入同步的界面,我们就从这里开始分析。
在途中最重要的是要分析一下这个区域的东西。
分析:第一个图标是重新同步,如果在你同步的过程中还有人提交了文件,那么点击这个就会重新同步;第二:一个加号的那个是你自己有没有添加文件,如果有添加的文件上就会出现一个加号图标,减号也一样,如果你删除了文件上一样会出现一个减号的图。第三:蓝色的图标是别人提交的东西;第四:想右的灰色箭头是你要提交的东西或者是修改的东西;第五:如果是全部的;而第六个红色的箭头的是别人的东西和你提交的东西改到了同一个地方。
其实红色箭头是需要处理的,这是需要双击文件,如果在两个文件区域没有红色的区域那就可以直接更新,然后在提交,如果有红色的区域,你需要解决一下冲突,你可以把你写的东西换到其他的行中,这样就不会冲突了,也可以两个改的相通即可。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)