版本控制SVN,Local delete, incoming delete upon update

svn local delete, incoming delete upon update 解决办法

 

一、

1. svn local delete, incoming delete upon update 解决办法
2. # 1.In your working directory, recreate that conflicting file:
3. $ touch foo
4. # 2.Revert that file to the state SVN likes (that means deleted):
5. $ svn revert foo
6. # 3.Now delete that file:
7. $ rm foo
8. # 4.Conflict resolved:
9. $ svn st
10. # Done.

最后还需要指定更新文件：svn up application.js

二、

删除文件夹后点commit提交，但是报错，报错内容如下：

提示 "svn: Commit failed (details follow): svn: '/***/xxx.c' is scheduled for addition, but is missing "

原因：之前用SVN提交过的文件，被标记为"add"状态，等待被加入到仓库。若此时你把这个文件删除了，SVN提交的时候还是会尝试提交这个文件，虽然它的状态已经是 "missing"了。

解决：在命令行下用 "svn revert xxx.c --depth infinity"，在图形界面下，右键--Revert，选中那个文件。这样就告诉SVN把这个文件退回到之前的状态 "unversioned"，也就是不对这个文件做任何修改

三、

错误提示：

svn: '/Users/qrh/Desktop/work/svn/yb2.0/TVAPP/Images/share/moviePause@2x.png' is scheduled for addition, but is missing

 

错误原因：

产生问题的原因是有一个文件已经加入到版本库中，但是后来在文件系统中又移除了这个文件，所以不能够提交。

 

解决方法：

svn revert /Users/qrh/Desktop/work/svn/yb2.0/TVAPP/Images/share/moviePause@2x.png 

svn ci -m "update"

四、

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

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

出现冲突时，一般会提示冲突的信息是什么。过后我们可以使用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的修改时会提示冲突。重命名后的文件被标记为新增，原来文件被标记为树冲突。

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