本节简单介绍一下SVN文件冲突和SVN树冲突在本地的解决方法，在这里和大家分享一下，看完本文你肯定有不少收获，希望本文能教会你更多东西，让我们一起来学习SVN文件冲突和SVN树冲突的解决方法吧。
1.本地删除，当更新时有删除进入开发人员A将文件Foo.c改名为Bar.c并将其提交至版本库中。
开发人员B将文件Foo.c改名为Bix.c
更新开发人员B的工作副本会导致树冲突:
Bix.c被标记为添加(包括其历史记录)。
Bar.c被添加到工作副本中，其状态为‘正常’。
Foo.c被标记为删除并且产生一个SVN树冲突。
要解决这个冲突，开发人员B必须找出冲突的文件Foo.c经过改名/移动后在版本库中的新文件名是什么。可以使用日志对话框来完成这个任务。
然后，开发人员B需要决定Foo.c的新文件名中的哪一个需要保留-开发人员A改的那个还是他自己改的那个。
在开发人员B手工解决冲突后，使用冲突编辑对话框中的按钮将树冲突标记为已解决。
本地缺少，当合并时有更改进入开发人员A在主干上工作，修改Foo.c并将其提交至版本库中
开发人员B在分支上工作，将Foo.c改名为Bar.c并将其提交至版本库中
合并开发人员A的主干更改到开发人员B的分支工作副本会导致SVN树冲突:
Bar.c已经存在于工作副本中，其状态为‘正常’。
Foo.c被标记为缺少并产生SVN树冲突。
要解决这个冲突，开发人员B要在冲突编辑对话框中标记文件为已解决，这样就会将其从冲突列表中删除。她接下来需要决定是否将缺少的文件Foo.c从版本库中复制到工作副本中，是否将开发人员A的对Foo.c的更改和合并到改名后的Bar.c或者是否通过标记冲突为已解决来忽略更改什么事也不做。
注意，如果你将缺少的文件从版本库中复制到工作副本中然后再标记为已解决，你复制下来的文件将被再次删除。你必须先解决冲突。
2.本地更改，当合并时有删除进入开发人员A在主干上工作，将Foo.c改名为Bar.c并将其提交至版本库中
开发人员B在分支上工作，修改Foo.c并将其提交至版本库中
当文件夹改名时有类似的案例，但是在Subversion1.6中还未被识别...
开发人员A在主干上工作，将父文件夹FooFolder改名为BarFolder并将其提交至版本库中。
开发人员B在分支上工作，在她的工作副本中修改Foo.c。
合并开发人员A的主干更改到开发人员B的分支工作副本会导致SVN树冲突:
Bar.c被标记为添加。
Foo.c被标记为修改并产生SVN树冲突。
开发人员B现在需要做出决定是否接受开发人员A作出的结构改变并且合并她的更改到新结构下适当的文件中，或者直接放弃开发人员A的更改并保留本地文件。
要合并她的本机更改到新布局中，开发人员B必须先找出冲突的文件Foo.c经过改名/移动后在版本库中的新文件名是什么。可以通过适用于合并源码的日志对话框来完成这个任务。冲突编辑器仅显示工作副本的日志因为它不知道将哪个路径的更改合并进来，所以你需要自己找到它。更改必须要手工合并，因为没有办法自动的或者简单的完成此操作。一旦更改移植完毕，冲突的路径就是多余的并且可以删除。在此案例中，使用冲突编辑对话框中的删除按钮进行清理并将冲突标记为已解决。
如果开发人员B认为A的更改是错误的，那么在冲突编辑对话框中她必须选择保留按钮。这样就会标记冲突的文件/文件夹为已解决，但是需要手工删除开发人员A的更改。又是通过日志对话框帮助追踪哪些文件移动了。
本地删除，当合并时有删除进入开发人员A在主干上工作，将Foo.c改名为Bar.c并将其提交至版本库中
开发人员B工作在分之上，将Foo.c改名为Bix.c并将其提交至版本库中
3.合并开发人员A的主干更改到开发人员B的分支工作副本会导致SVN树冲突:
Bix.c被标记为正常(未修改)状态。
Bar.c被标记为添加(包括其历史记录)。
Foo.c被标记为缺少并且产生树冲突。
要解决这个冲突，开发人员B必须先找出冲突的文件Foo.c经过改名/移动后在版本库中的新文件名是什么。可以通过适用于合并源码的日志对话框来完成这个任务。冲突编辑器仅显示工作副本的日志因为它不知道将哪个路径的更改合并进来，所以你需要自己找到它。
然后，开发人员B需要决定Foo.c的新文件名中的哪一个需要保留-开发人员A改的那个还是他自己改的那个。
在开发人员B手工解决冲突后，使用冲突编辑对话框中的按钮将树冲突标记为已解决。本节关于SVN文件冲突和SVN树冲突内容讲解完毕，请关注本节其他相关报道。
【编辑推荐】
