- 本文向大家介绍一下SVN冲突问题中的SVN文件冲突和树冲突问题,在这里和大家分享一下，希望通过本文的学习大家对SVN冲突问题有清晰的认识。
本节和大家一起学习一下SVN文件冲突和树冲突，主要包括SVN文件冲突和树冲突如何出现，以及怎样解决这些冲突，希望通过本文的学习大家能够掌握住这些方法。
解决冲突
偶尔，当你从版本库更新、合并文件时，或者切换工作副本至一个不同的URL时你会遇到冲突。有两种冲突:
SVN文件冲突
当两名(或更多)开发人员修改了同一个文件中相邻或相同的行时就会发生文件冲突。
SVN树冲突
当一名开发人员移动、重命名、删除一个文件或文件夹，而另一名开发人员也对它们进行了移动、重命名、删除或者仅仅是修改时就会发生树冲突。
SVN文件冲突
当两名或更多开发人员修改了同一个文件中相邻或相同的行时就会发生文件冲突。由于Subversion不知道你的项目的具体情况，它把解决冲突的工作留给了开发人员。一旦出现冲突，你就应该打开有问题的文件，查找以字符串<<<<<<<开头的行。有冲突的区域用如下的方式标记:
<<<<<<<文件名你的修改=======合并自版本库中的代码>>>>>>>版本
对于每个冲突的文件Subversion在你的目录下放置了三个文件:
文件名.ext.mine
这是你的文件，在你更新你的工作副本之前存在于你的的工作副本中——也就是说，没有冲突标志。这个文件除了你的最新修改外没有别的东西。
文件名.ext.r旧版本
这是在你更新你的工作副本之前的基础版本(BASErevision)文件。也就是说，它是在你做最后修改之前所检出的文件。
文件名.ext.r新版本
这个文件是当你更新你的工作副本时，你的Subversion客户端从服务器接收到的。这个文件对应于版本库中的最新版本。
你可以通过TortoiseSVN→编辑冲突运行外部合并工具/冲突编辑器，或者你可以使用任何别的编辑器手动解决冲突。你需要冲定哪些代码是需要的，做一些必要的修改然后保存。
然后，执行命令TortoiseSVN→已解决并提交人的修改到版本库。需要注意的是已解决命令并不是真正的解决了冲突，它只是删除了filename.ext.mine和filename.ext.r*两个文件，允许你提交修改。
如果你有二进制SVN文件冲突，Subversion不会试图合并文件。本地文件保持不变(完全是你最后修改时的样子)，但你会看到filename.ext.r*文件。如果你要撤消你的修改，保留版本库中的版本，请使用还原(Revert)命令。如果你要保持你的版本覆盖版本库中的版本，使用已解决命令，然后提交你的版本。
你可以右击父文件夹，选择TortoiseSVN→已解决...，使用“已解决”命令来解决多个文件。这个操作会出现一个对话框，列出文件夹下所有有冲突的文件，你可以选择将哪些标记成已解决。
树冲突
当一名开发人员移动、重命名、删除一个文件或文件夹，而另一名开发人员也对它们进行了移动、重命名、删除或者仅仅是修改时就会发生树冲突。有很多种不同的情形可以导致树冲突，而且不同的情形需要不同的步骤来解决冲突。
当一个文件通过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的更改。又是通过日志对话框帮助追踪哪些文件移动了。请期待下节SVN文件冲突和树冲突问题讲解。
解决冲突
偶尔，当你从版本库更新、合并文件时，或者切换工作副本至一个不同的URL时你会遇到冲突。有两种冲突:
SVN文件冲突
当两名(或更多)开发人员修改了同一个文件中相邻或相同的行时就会发生文件冲突。
SVN树冲突
当一名开发人员移动、重命名、删除一个文件或文件夹，而另一名开发人员也对它们进行了移动、重命名、删除或者仅仅是修改时就会发生树冲突。
SVN文件冲突
当两名或更多开发人员修改了同一个文件中相邻或相同的行时就会发生文件冲突。由于Subversion不知道你的项目的具体情况，它把解决冲突的工作留给了开发人员。一旦出现冲突，你就应该打开有问题的文件，查找以字符串<<<<<<<开头的行。有冲突的区域用如下的方式标记:
<<<<<<<文件名你的修改=======合并自版本库中的代码>>>>>>>版本
对于每个冲突的文件Subversion在你的目录下放置了三个文件:
文件名.ext.mine
这是你的文件，在你更新你的工作副本之前存在于你的的工作副本中——也就是说，没有冲突标志。这个文件除了你的最新修改外没有别的东西。
文件名.ext.r旧版本
这是在你更新你的工作副本之前的基础版本(BASErevision)文件。也就是说，它是在你做最后修改之前所检出的文件。
文件名.ext.r新版本
这个文件是当你更新你的工作副本时，你的Subversion客户端从服务器接收到的。这个文件对应于版本库中的最新版本。
你可以通过TortoiseSVN→编辑冲突运行外部合并工具/冲突编辑器，或者你可以使用任何别的编辑器手动解决冲突。你需要冲定哪些代码是需要的，做一些必要的修改然后保存。
然后，执行命令TortoiseSVN→已解决并提交人的修改到版本库。需要注意的是已解决命令并不是真正的解决了冲突，它只是删除了filename.ext.mine和filename.ext.r*两个文件，允许你提交修改。
如果你有二进制SVN文件冲突，Subversion不会试图合并文件。本地文件保持不变(完全是你最后修改时的样子)，但你会看到filename.ext.r*文件。如果你要撤消你的修改，保留版本库中的版本，请使用还原(Revert)命令。如果你要保持你的版本覆盖版本库中的版本，使用已解决命令，然后提交你的版本。
你可以右击父文件夹，选择TortoiseSVN→已解决...，使用“已解决”命令来解决多个文件。这个操作会出现一个对话框，列出文件夹下所有有冲突的文件，你可以选择将哪些标记成已解决。
树冲突
当一名开发人员移动、重命名、删除一个文件或文件夹，而另一名开发人员也对它们进行了移动、重命名、删除或者仅仅是修改时就会发生树冲突。有很多种不同的情形可以导致树冲突，而且不同的情形需要不同的步骤来解决冲突。
当一个文件通过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的更改。又是通过日志对话框帮助追踪哪些文件移动了。请期待下节SVN文件冲突和树冲突问题讲解。
【编辑推荐】
