svn解决冲突

SVN 解决冲突

---

版本冲突原因：

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

我们已在本地检出 runoob01 库，下面我们将实现版本冲突的解决方法。

我们发现 HelloWorld.html 文件存在错误，需要修改文件并提交到版本库中。

我们将 HelloWorld.html 的内容修改为 "HelloWorld! http://www.runoob.com/"。

root@runoob:~/svn/runoob01/trunk# cat HelloWorld.html 
HelloWorld! http://www.runoob.com/

用下面的命令查看更改：

root@runoob:~/svn/runoob01/trunk# svn diff 
Index: HelloWorld.html
===================================================================
--- HelloWorld.html     (revision 5)
+++ HelloWorld.html     (working copy)
@@ -1,2 +1 @@
-HelloWorld! http://www.runoob.com/
+HelloWorld! http://www.runoob.com/!

尝试使用下面的命令来提交他的更改：

root@runoob:~/svn/runoob01/trunk# svn commit -m "change HelloWorld.html first"
Sending        HelloWorld.html
Transmitting file data .svn: E160028: Commit failed (details follow):
svn: E160028: File '/trunk/HelloWorld.html' is out of date

这时我发现提交失败了。

因为此时，HelloWorld.html 已经被 user02 修改并提交到了仓库。Subversion 不会允许 user01(本例使用的 svn 账号)提交更改，因为 user02 已经修改了仓库，所以我们的工作副本已经失效。

为了避免两人的代码被互相覆盖，Subversion 不允许我们进行这样的操作。所以我们在提交更改之前必须先更新工作副本。所以使用 update 命令，如下：

root@runoob:~/svn/runoob01/trunk# svn update
Updating '.':
C    HelloWorld.html
Updated to revision 6.
Conflict discovered in file 'HelloWorld.html'.
Select: (p) postpone, (df) show diff, (e) edit file, (m) merge,
        (mc) my side of conflict, (tc) their side of conflict,
        (s) show all options: mc
Resolved conflicted state of 'HelloWorld.html'
Summary of conflicts:
  Text conflicts: 0 remaining (and 1 already resolved)

这边输入"mc",以本地的文件为主。你也可以使用其选项对冲突的文件进行不同的操作。

默认是更新到最新的版本，我们也可以指定更新到哪个版本

svn update -r6

此时工作副本是和仓库已经同步，可以安全地提交更改了

root@runoob:~/svn/runoob01/trunk# svn commit -m "change HelloWorld.html second"
Sending        HelloWorld.html
Transmitting file data .
Committed revision 7.

SVN冲突 树冲突（三）

(2012-12-04 18:52:59)

转载▼

标签： svn 树冲突 树冲突原因 杂谈

分类： 解决问题

    经常有人会说，树冲突是很难解决的一类冲突，其实一旦了解了其原理，要解决也不难。先回顾下对于树冲突的定义。

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

出现冲突时，一般会提示冲突的信息是什么。过后我们可以使用svn st来查看当前状态。svn st的各种状态代表什么，请参考此博文svn st状态详解。

先介绍一下概念

Delete ： 其中目录结构变化，都认为是Delete

Edit： 是指修改文件

Local ： 是你本地修改

Incoming ：是别人修改，你要Update或Merge进来。

这样应该有4个组合，但是Edit对Edit的组合应该是File Conflict，这个容易解决，不在Tree Conflict 讨论范围，所以有3种组合。再需要区别Update和Merge，就有了6种情况。分别是

Local delete, incoming edit upon update

Local edit, incoming delete upon update

Local delete, incoming delete upon update

Local missing, incoming edit upon merge

Local edit, incoming delete upon merge

Local delete, incoming delete upon merge

分别对这几种情形解释如下：

1.Local delete, incoming edit upon update（本地删除，更新后传入修改）

产生原因：1.A修改文件Foo.c后提交到版本库中，B将Foo.c重命名为Bar.c或者删除了Foo.c或者直接将Foo.c的父目录Foo直接删除 2.B更新工作副本会提示该冲突，在working copy显示为Foo.c在本地删除，被标记为冲突。如果是重命名，则Bar.c被标记为新增，但是不包括A的修改。

解决：A与B要确认是否采用A的修改与是否重命名。如果采用A的修改，并且要重命名则修改后，标记冲突解决，svn resolved，最后提交；如果不采用A的修改，直接标记冲突解决提交即可。

2.Local edit, incoming delete upon update （本地编辑，更新后传入删除）

产生原因：1.A对Foo.c重命名为Bar.c并提交到版本库（或者A将Foo.c的上级目录Foo修改为Bar），B在他的工作副本中对Foo.c进行修改。2.B提交前更新，会提示如此错误。

解决：同样需要两个人进行协商后修改。

3.Local delete, incoming delete upon update （本地删除，更新后传入删除）

产生原因：1.A将Foo.c重命名为Bar.c后提交，B对Foo.c重命名为Bix.c。2.B更新本地工作副本是会提示该树冲突。

解决：通过日志查找文件被删除即重命名的原因，A与B协商后最终确认采用哪个名称。

4.Local missing, incoming edit upon merge （本地丢失，合并后传入修改）

产生原因：1.A在主干上修改Foo.c，B在分支上将Foo.c重命名为Bar.c。2.B合并A在主干上的修改。

解决：B先标记冲突解决，然后将Foo.c拷贝至本地，将A的修改合并至自己的文件中或者直接放弃A的修改，采用自己的修改。

5.Local edit, incoming delete upon merge （本地修改，合并后传入删除）

产生原因：1.A将Foo.c重命名为Bar.c(或者将Foo.c的父目录Foo改为Bar)，B在分支上修改Foo.c。2.B合并A的修改时提示该冲突。Bar.c被标记为增加，Foo.c被标记为冲突。

解决：同样根据日志查找到修改的源头，两人协商后解决。

6.Local delete, incoming delete upon merge （本地删除，合并后传入删除）

产生原因：1.A在主干上将Foo.c重命名为Bar.c，B在分支上将Foo.c重命名为Bix.c。2.B合并A的修改时会提示冲突。重命名后的文件被标记为新增，原来文件被标记为树冲突。

解决：通过日志查找到文件被改名的时刻，两人协商后解决。