svn 解决冲突

当一名开发人员移动、重命名、删除一个文件或文件夹，而另一名开发人员也对它们进行了移动、重命名、删除或者仅仅是修改时就会发生树冲突。有很多种不同的情形可以导致树冲突，而且不同的情形需要不同的步骤来解决冲突。
当一个文件通过Subversion在本机删除后，文件也从本机文件系统中删除。因此即使它是树冲突的一部分，却既不能显示冲突的叠加图标也不能通过右键单击来解决冲突。使用检查修改对话框来获得编辑冲突选项。
TortoiseSVN能够协助找到合并更改的正确位置，但是需要作一些额外的工作来整理冲突。请牢记:当进行一次更新操作后，工作副本的基础文件将会包括每一个项目在执行更新操作时版本库中的版本。如果你在进行更新后再撤销更改，工作副本将返回到版本库的状态，而不是你开始进行更改前的状态。
本地删除，当更新时有更改进入开发人员A修改Foo.c并将其提交至版本库中
开发人员B同时在他的工作副本中将文件Foo.c改名为Bar.c，或者仅仅是删除了Foo.c或它的父文件夹。
更新开发人员B的工作副本会导致树冲突:
在工作副本中，Foo.c被删除了，但是被标记为树冲突。
如果冲突是由于更改文件名引起的而不是删除文件引起的，那么Bar.c被标记为添加，但是其中却不包括开发人员A修改的内容。
开发人员B现在必须做出选择是否保留开发人员A的更改。在更改文件名的案例中，他可以将Foo.c的更改合并到改名后的文件Bar.c中去。对于删除文件或文件夹的案例中，他可以选择保留包含开发人员A更改内容的项目并放弃删除操作。或什么也不做而直接将冲突标记为已解决，那样他实际上丢弃了开发人员A的更改。
如果TortoiseSVN能够找到被改名为Bar.c的原始文件，冲突编辑对话框将可以合并更改。这取决于在什么地方调用更新操作，它也许不能找到原始文件。
本地更改，当更新时有删除进入开发人员A将文件Foo.c改名为Bar.c并将其提交至版本库中。
开发人员B在他的工作副本中修改文件Foo.c。或者在一个文件夹改名的案例中...
开发人员A将父文件夹FooFolder改名为BarFolder并将其提交至版本库中。
开发人员B在他的工作副本中修改文件Foo.c。
更新开发人员B的工作副本会导致树冲突。对于一个简单的SVN文件冲突:
Bar.c被当作一个正常文件添加到工作副本中。
Foo.c被标记为添加(包括其历史记录)并且产生树冲突。
对于一个文件夹冲突:
BarFolder被当作一个正常文件夹添加到工作副本中。
FooFolder被标记为添加(包括其历史记录)并且产生树冲突。
Foo.c被标记为已修改。
开发人员B现在需要做出决定是否接受开发人员A作出的结构改变并且合并她的更改到新结构下适当的文件中，或者直接放弃开发人员A的更改并保留本地文件。
要合并她的本机更改到新布局中，开发人员B必须先找出冲突的文件Foo.c经过改名/移动后在版本库中的新文件名是什么。可以使用日志对话框来完成这个任务。更改必须要手工合并，因为没有办法自动的或者简单的完成此操作。一旦更改移植完毕，冲突的路径就是多余的并且可以删除。在此案例中，使用冲突编辑对话框中的删除按钮进行清理并将冲突标记为已解决。
如果开发人员B认为A的更改是错误的，那么在冲突编辑对话框中她必须选择保留按钮。这样就会标记冲突的文件/文件夹为已解决，但是需要手工删除开发人员A的更改。又是通过日志对话框帮助追踪哪些文件移动了。