解决版本冲突

解决版本冲突的命令。在冲突解决之后，需要使用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时每次都是先提交，后更新。每天早上打开项目后，首先要从版本库获取最新版本。每天下班后必须将能够编译过去的程序签入到版本库。

 

提交的时候提示版本过期：首先应该从版本库更新版本，然后去解决冲突，冲突解决后要执行svn resolved ，然后在签入到版本库。

本节向大家讲解一下SVN冲突的解决方法，在这里和大家分享一下，看完本文你肯定有不少收获，希望本文能教会你更多东西，欢迎打击一起来学习SVN冲突方面的知识。
本人使用SVN的时间不是很长，在使用之前也仅仅是粗浅的了解过这个软件。从今年的8月份开始，由于一个项目使用Eclipse3.1，跨地域的开发，为了适应不同的开发人员处于不同的地理位置，因此我们使用SVN作为团队开发的管理工具。开始使用时，仅仅是边学边用，遇到不懂的地方再去查找资料。今天由于有点时间，先把合并过程遇到的冲突问题详细了解一下。
可以使用svnstatus-u命令来查看一下某个问题是否会有冲突发生。在使用svnupdate的时候，会出现如下一些信息：
$svnupdate
UINSTALL
GREADME
Cbar.c
Updatedtorevision46.
那么，U开头的信息提示你，这个文件在你本地没有修改过，文件已经根据版本库的新版本更新了。G开头的信息提示你，这个文件在你本地已经修改过，但是和版本库中对应的版本并没有冲突的地方，svn已经合并更新了。而C开头的信息提示你，这个文件有点麻烦，你在本地的修改和版本库中的版本修改的地方重叠了，也就是说，你修改了某一行，你的同事也修改了同一行。这个就需要你自己手工去解决了。当冲突发生时，要注意到有三件事情可以帮助你解决问题。
a.Subversion会给这个文件作出c标记。
b.如果Subversion认为这个文件时可以合并的，它会一个冲突标记（特殊的横线来分开冲突的代码块）
c.对每一个冲突的文件，Subversion放置三个额外的未版本化文件到你的工作拷贝。
filename.mine
你更新前的文件，没有SVN冲突标志，只是你最新更改的内容。（如果这个文件不可以合并，.mine文件不会创建，因为它和工作文件相同。）
filename.rOLDREV
这个是你做更新操作以前的BASE版本，就是你在上次更新之后未作更改的版本。
filename.rNEWREV
这是Subversion从服务器刚刚收到的版本。这个版本就是版本库的HEAD版本。
例如，如果sally修改了一个文件sandwich.txt,而harry也刚刚修改了这个文件的相同位置并提交到服务器。那么sally在做这个文件的update操作的时候会得到三个额外的文件sandwich.txt.mine、sandwich.txt.r1、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冲突区中，或许你需要和你的同事沟通来安排冲突区的文本内容，如果是程序代码，你需要和同事商量一下，中间的这段代码到底应该是什么样子的。
所有冲突区得到合理的解决之后，你就可以提交你的文件了。

1、  如何产生冲突

当开发人员A和开发人员B从版本库同时检出文档1.txt，而A和B同时修改了1.txt的同一地方，后提交的一方会在拷贝副本中产生冲突。

两个工作拷贝，A拷贝中文件1.txt内容为

dfqerq
123dfwre

B拷贝中文件1.txt内容为

dfqerq
123erwrq

在B版本提交之前版本库上的1.txt（base版本）内容为

dfqerq

 

B拷贝先提交版本到版本库中，以至于最新版本内容变为

dfqerq
123erwrq

 

此时A版本也提交则会产生冲突，无法提交，需要先svn update，此时会在A拷贝中产生三个临时文件1.txt.rNew\1.txt.rOld\1.txt.mine，其中1.txt.rNew是最新版 本，1.txt.rOld是base版本，1.txt.mine是A作者修改后的版本，在此例中内容为

dfqerq
123dfwre

而update之后A拷贝中的1.txt内容为

<<<<<<< .mine
dfqerq
123dfwre=======
dfqerq
123erwrq>>>>>>> .r18

其中<<<<<<< .mine与=======之间表示A修改后的内容，=======与>>>>>>> .r18之间是版本服务器上的版本

 

2、解决冲突

第一种，利用update的选项进行冲突解决，也就是说不管当前拷贝副本是否是最新版本，都使用—accept参数作为冲突处理方式

–accept ARG             : specify automatic conflict resolution action
(‘postpone’, ‘base’, ‘mine-conflict’,
‘theirs-conflict’, ‘mine-full’, ‘theirs-full’,
‘edit’, ‘launch’)

(p)  postpone    – mark the conflict to be resolved later //让文件在更新完成之后保持冲突状态。
(df) diff-full   – show all changes made to merged file //使用标准区别格式显示base修订版本和冲突文件本身的区别。
(e)  edit        – change merged file in an editor //用你喜欢的编辑器打开冲突的文件，编辑器是环境变量EDITOR设置的。
(r)  resolved    – accept merged version of file //完成文件编辑之后，通知svn你已经解决了文件的冲突，它必须接受当前的内容—从本质上讲就是你已经“解决了”冲突。
(mf) mine-full   – accept my version of entire file (ignore their change//丢弃新从服务器接收的变更，并只使用你查看文件的本地修改。
(tf) theirs-full – accept their version of entire file (lose my changes)//丢弃你对查看文件的本地修改，只使用从服务器新接收的变更。
(l)  launch      – launch external tool to resolve conflict//启动一个外置程序来执行冲突解决，这需要一些预先的准备。
(h)  help        – show this list //显示所有在冲突解决时可能使用的命令。

 

第二种，在update时并不处理冲突，利用svn resolve解决冲突

1、利用svn resolve –accept base选择base版本，即1.txt.rOld作为最后提交的版本

–accept ARG             : specify automatic conflict resolution source
(‘base’, ‘working’, ‘mine-conflict’,
‘theirs-conflict’, ‘mine-full’, ‘theirs-full’)

 

2、手工修改1.txt文件，然后将当前拷贝即1.txt作为最后提交的版本

svn resolve –accept working 1.txt

3、svn resolve –accept theirs-full 1.txt 使用1.txt.rNew作为最后提交的版本

4、svn resolve –accept mine-full 1.txt 使用1.txt.mine作为最后提交的版本

5、svn resolve –accept mine-conflict 1.txt 使用1.txt.mine的冲突部分作为最后提交的版本

5、svn resolve –accept theirs-conflict 1.txt 使用1.txt.rNew的冲突部分作为最后提交的版本

 

第三种，使用svn revert取消变更

（以上文章来源：http://blog.sina.com.cn/s/blog_65fd4c1e0100h2cg.html）

－－－－－

前两天在解决冲突时用到了svn resolve这个命令，找到这篇文章主要是因为他对–accept参数的说明比较全

比官方的文档更详细。

svn文件冲突,树冲突详解

解决冲突

偶尔，当你从版本库更新、合并文件时，或者切换工作副本至一个不同的 URL 时你会遇到冲突。有两种冲突:

文件冲突

当两名(或更多)开发人员修改了同一个文件中相邻或相同的行时就会发生文件冲突。

树冲突

当一名开发人员移动、重命名、删除一个文件或文件夹，而另一名开发人员也对它们进行了移动、重命名、删除或者仅仅是修改时就会发生树冲突。

文件冲突

当两名或更多开发人员修改了同一个文件中相邻或相同的行时就会发生文件冲突。由于 Subversion 不知道你的项目的具体情况，它把解决冲突的工作留给了开发人员。一旦出现冲突，你就应该打开有问题的文件，查找以字符串<<<<<<<开头的行。有冲突的区域用如下的方式标记:

<<<<<<< 文件名
  你的修改
 =======
  合并自版本库中的代码
 >>>>>>> 版本

对于每个冲突的文件 Subversion 在你的目录下放置了三个文件:

文件名.ext.mine

这是你的文件，在你更新你的工作副本之前存在于你的的工作副本中——也就是说，没有冲突标志。这个文件除了你的最新修改外没有别的东西。

文件名.ext.r旧版本

这是在你更新你的工作副本之前的基础版本(BASE revision)文件。也就是说，它是在你做最后修改之前所检出的文件。

文件名.ext.r新版本

这个文件是当你更新你的工作副本时，你的 Subversion 客户端从服务器接收到的。这个文件对应于版本库中的最新版本。

你可以通过TortoiseSVN → 编辑冲突运行外部合并工具/冲突编辑器，或者你可以使用任何别的编辑器手动解决冲突。你需要冲定哪些代码是需要的，做一些必要的修改然后保存。

然后，执行命令TortoiseSVN → 已解决并提交人的修改到版本库。需要注意的是已解决命令并不是真正的解决了冲突，它只是删除了filename.ext.mine和filename.ext.r*两个文件，允许你提交修改。

如果你的二进制文件有冲突，Subversion不会试图合并文件。本地文件保持不变(完全是你最后修改时的样子)，但你会看到filename.ext.r*文件。如果你要撤消你的修改，保留版本库中的版本，请使用还原(Revert)命令。如果你要保持你的版本覆盖版本库中的版本，使用已解决命令，然后提交你的版本。

你可以右击父文件夹，选择TortoiseSVN → 已解决...，使用“已解决”命令来解决多个文件。这个操作会出现一个对话框，列出文件夹下所有有冲突的文件，你可以选择将哪些标记成已解决。

树冲突

当一名开发人员移动、重命名、删除一个文件或文件夹，而另一名开发人员也对它们进行了移动、重命名、删除或者仅仅是修改时就会发生树冲突。有很多种不同的情形可以导致树冲突，而且不同的情形需要不同的步骤来解决冲突。

当一个文件通过 Subversion 在本机删除后，文件也从本机文件系统中删除。因此即使它是树冲突的一部分，却既不能显示冲突的叠加图标也不能通过右键单击来解决冲突。使用检查修改对话框来获得编辑冲突选项。

TortoiseSVN 能够协助找到合并更改的正确位置，但是需要作一些额外的工作来整理冲突。请牢记: 当进行一次更新操作后，工作副本的基础文件将会包括每一个项目在执行更新操作时版本库中的版本。如果你在进行更新后再撤销更改，工作副本将返回到版本库的 状态，而不是你开始进行更改前的状态。

本地删除，当更新时有更改进入

1. 开发人员 A 修改 Foo.c 并将其提交至版本库中

2. 开发人员 B 同时在他的工作副本中将文件 Foo.c 改名为 Bar.c，或者仅仅是删除了 Foo.c 或它的父文件夹。

更新开发人员 B 的工作副本会导致树冲突:

• 在工作副本中，Foo.c 被删除了，但是被标记为树冲突。

• 如果冲突是由于更改文件名引起的而不是删除文件引起的，那么 Bar.c 被标记为添加，但是其中却不包括开发人员 A 修改的内容。

开发人员 B 现在必须做出选择是否保留开发人员 A 的更改。在更改文件名的案例中，他可以将 Foo.c 的更改合并到改名后的文件 Bar.c 中去。对于删除文件或文件夹的案例中，他可以选择保留包含开发人员 A 更改内容的项目并放弃删除操作。或什么也不做而直接将冲突标记为已解决，那样他实际上丢弃了开发人员 A 的更改。

如果 TortoiseSVN 能够找到被改名为 Bar.c 的原始文件，冲突编辑对话框将可以合并更改。这取决于在什么地方调用更新操作，它也许不能找到原始文件。

本地更改，当更新时有删除进入

1. 开发人员 A 将文件 Foo.c 改名为 Bar.c 并将其提交至版本库中。

2. 开发人员 B 在他的工作副本中修改文件 Foo.c。

或者在一个文件夹改名的案例中...

1. 开发人员 A 将父文件夹 FooFolder 改名为 BarFolder 并将其提交至版本库中。

2. 开发人员 B 在他的工作副本中修改文件 Foo.c。

更新开发人员 B 的工作副本会导致树冲突。对于一个简单的文件冲突:

• Bar.c 被当作一个正常文件添加到工作副本中。

• Foo.c 被标记为添加(包括其历史记录)并且产生树冲突。

对于一个文件夹冲突:

• BarFolder 被当作一个正常文件夹添加到工作副本中。

• FooFolder 被标记为添加(包括其历史记录)并且产生树冲突。

  Foo.c 被标记为已修改。

开发人员 B 现在需要做出决定是否接受开发人员 A 作出的结构改变并且合并她的更改到新结构下适当的文件中，或者直接放弃开发人员 A 的更改并保留本地文件。

要合并她的本机更改到新布局中，开发人员 B 必须先找出冲突的文件 Foo.c 经过改名/移动后在版本库中的新文件名是什么。可以使用日志对话框来完成这个任务。更改必须要手工合并，因为没有办法自动的或者简单的完成此操作。一旦更改移植完毕，冲突的路径就是多余的并且可以删除。在此案例中，使用冲突编辑对话框中的删除按钮进行清理并将冲突标记为已解决。

如果开发人员 B 认为 A 的更改是错误的，那么在冲突编辑对话框中她必须选择保留按钮。这样就会标记冲突的文件/文件夹为已解决，但是需要手工删除开发人员 A 的更改。又是通过日志对话框帮助追踪哪些文件移动了。

本地删除，当更新时有删除进入

1. 开发人员 A 将文件 Foo.c 改名为 Bar.c 并将其提交至版本库中。

2. 开发人员 B 将文件 Foo.c 改名为 Bix.c

更新开发人员 B 的工作副本会导致树冲突:

• Bix.c 被标记为添加(包括其历史记录)。

• Bar.c 被添加到工作副本中，其状态为‘正常’。

• Foo.c 被标记为删除并且产生一个树冲突。

要解决这个冲突，开发人员 B 必须找出冲突的文件 Foo.c 经过改名/移动后在版本库中的新文件名是什么。可以使用日志对话框来完成这个任务。

然后，开发人员 B 需要决定 Foo.c 的新文件名中的哪一个需要保留 - 开发人员 A 改的那个还是他自己改的那个。

在开发人员 B 手工解决冲突后，使用冲突编辑对话框中的按钮将树冲突标记为已解决。

本地缺少，当合并时有更改进入

1. 开发人员 A 在主干上工作，修改 Foo.c 并将其提交至版本库中

2. 开发人员 B 在分支上工作，将 Foo.c 改名为 Bar.c 并将其提交至版本库中

合并开发人员 A 的主干更改到开发人员 B 的分支工作副本会导致树冲突:

• Bar.c 已经存在于工作副本中，其状态为‘正常’。

• Foo.c 被标记为缺少并产生树冲突。

要解决这个冲突，开发人员 B 要在冲突编辑对话框中标记文件为已解决，这样就会将其从冲突列表中删除。她接下来需要决定是否将缺少的文件 Foo.c 从版本库中复制到工作副本中，是否将开发人员 A 的对 Foo.c 的更改和合并到改名后的 Bar.c 或者是否通过标记冲突为已解决来忽略更改什么事也不做。

注意，如果你将缺少的文件从版本库中复制到工作副本中然后再标记为已解决，你复制下来的文件将被再次删除。你必须先解决冲突。

本地更改，当合并时有删除进入

1. 开发人员 A 在主干上工作，将 Foo.c 改名为 Bar.c 并将其提交至版本库中

2. 开发人员 B 在分支上工作，修改 Foo.c 并将其提交至版本库中

当文件夹改名时有类似的案例，但是在 Subversion 1.6 中还未被识别...

1. 开发人员 A 在主干上工作，将父文件夹 FooFolder 改名为 BarFolder 并将其提交至版本库中。

2. 开发人员 B 在分支上工作，在她的工作副本中修改 Foo.c 。

合并开发人员 A 的主干更改到开发人员 B 的分支工作副本会导致树冲突:

• Bar.c 被标记为添加。

• Foo.c 被标记为修改并产生树冲突。

开发人员 B 现在需要做出决定是否接受开发人员 A 作出的结构改变并且合并她的更改到新结构下适当的文件中，或者直接放弃开发人员 A 的更改并保留本地文件。

要合并她的本机更改到新布局中，开发人员 B 必须先找出冲突的文件 Foo.c 经过改名/移动后在版本库中的新文件名是什么。可以通过适用于合并源码的日志对话框来完成这个任务。冲突编辑器仅显示工作副本的日志因为它不知道将哪个路 径的更改合并进来，所以你需要自己找到它。更改必须要手工合并，因为没有办法自动的或者简单的完成此操作。一旦更改移植完毕，冲突的路径就是多余的并且可 以删除。在此案例中，使用冲突编辑对话框中的删除按钮进行清理并将冲突标记为已解决。

如果开发人员 B 认为 A 的更改是错误的，那么在冲突编辑对话框中她必须选择保留按钮。这样就会标记冲突的文件/文件夹为已解决，但是需要手工删除开发人员 A 的更改。又是通过日志对话框帮助追踪哪些文件移动了。

本地删除，当合并时有删除进入

1. 开发人员 A 在主干上工作，将 Foo.c 改名为 Bar.c 并将其提交至版本库中

2. 开发人员 B 工作在分之上，将 Foo.c 改名为 Bix.c 并将其提交至版本库中

合并开发人员 A 的主干更改到开发人员 B 的分支工作副本会导致树冲突:

• Bix.c 被标记为正常(未修改)状态。

• Bar.c 被标记为添加(包括其历史记录)。

• Foo.c 被标记为缺少并且产生树冲突。

要解决这个冲突，开发人员 B 必须先找出冲突的文件 Foo.c 经过改名/移动后在版本库中的新文件名是什么。可以通过适用于合并源码的日志对话框来完成这个任务。冲突编辑器仅显示工作副本的日志因为它不知道将哪个路径的更改合并进来，所以你需要自己找到它。

然后，开发人员 B 需要决定 Foo.c 的新文件名中的哪一个需要保留 - 开发人员 A 改的那个还是他自己改的那个。

在开发人员 B 手工解决冲突后，使用冲突编辑对话框中的按钮将树冲突标记为已解决。

关于我的解决方法
本人遇到这个问题,不管怎么样都无法删除。最后只得删除本地的所有文件，重新更新库。然后再删除想要删除的文件，最后提交。不在出现这个问题了。