【转】SVN 解决冲突

解决冲突
上一页	第 4 章日常使用指南	下一页

解决冲突

偶尔，当你从版本库更新、合并文件时，或者切换工作副本至一个不同的 URL 时你会遇到冲突。有两种冲突:

文件冲突

当两名(或更多)开发人员修改了同一个文件中相邻或相同的行时就会发生文件冲突。

树冲突

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

文件冲突

A file conflict occurs when two or more developers have changed the same few lines of a file. As Subversion knows nothing of your project, it leaves resolving the conflicts to the developers. The conflicting area in a text file is marked like this:

<<<<<<< filename
your changes
=======
code merged from repository
>>>>>>> revision

Also, for every conflicted file Subversion places three additional files in your directory:

文件名.扩展名.mine

这是你的文件，在你更新你的工作副本之前存在于你的的工作副本中——也就是说，没有冲突标志。这个文件除了你的最新修改外没有别的东西。

文件名.扩展名.r旧版本

这是在你更新你的工作副本之前的基础版本(BASE revision)文件。也就是说，它是在你做最后修改之前所检出的文件。

文件名.扩展名.r新版本

这个文件是当你更新你的工作副本时，你的 Subversion 客户端从服务器接收到的。这个文件对应于版本库中的最新版本。

You can either launch an external merge tool / conflict editor with TortoiseSVN → Edit Conflicts or you can use any text editor to resolve the conflict manually. You should decide what the code should look like, do the necessary changes and save the file. Using a merge tool such as TortoiseMerge or one of the other popular tools is generally the easier option as they generally present the files involved in a 3-pane view and you don't have to worry about the conflict markers. If you do use a text editor then you should search for lines starting with the string <<<<<<<.

然后，执行命令 TortoiseSVN → 已解决并提交人的修改到版本库。需要注意的是已解决命令并不是真正的解决了冲突，它只是删除了文件 文件名.扩展名.mine 和 文件名.扩展名.r*，允许你提交修改。

如果你的二进制文件有冲突，Subversion不会试图合并文件。本地文件保持不变(完全是你最后修改时的样子)，但你会看到文件名.扩展名.r*文件。如果你要撤消你的修改，保留版本库中的版本，请使用 SVN 还原(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 的更改。

The conflict edit dialog offers to merge changes if it can find the original file of the renamed Bar.c. If there are multiple files that are possible move sources, then a button for each of these files is shown which allow you to chose the correct file.

本地更改，当更新时有删除进入

开发人员 A 将文件 Foo.c 改名为 Bar.c 并将其提交至版本库中。
开发人员 B 在他的工作副本中修改文件 Foo.c。

或者在一个文件夹改名的案例中...

开发人员 A 将父文件夹 FooFolder 改名为 BarFolder 并将其提交至版本库中。
开发人员 B 在他的工作副本中修改文件 Foo.c。

更新开发人员 B 的工作副本会导致树冲突。对于一个简单的文件冲突:

Bar.c 被当作一个正常文件添加到工作副本中。
Foo.c 被标记为添加(包括其历史记录)并且产生树冲突。

对于一个文件夹冲突:

BarFolder 被当作一个正常文件夹添加到工作副本中。
FooFolder 被标记为添加(包括其历史记录)并且产生树冲突。

Foo.c 被标记为已修改。

开发人员 B 现在需要做出决定是否接受开发人员 A 作出的结构改变并且合并她的更改到新结构下适当的文件中，或者直接放弃开发人员 A 的更改并保留本地文件。

If Developer B decides that A's changes were wrong then she must choose the Mark as resolved button in the conflict editor dialog. This marks the conflicted file/folder as resolved, but Developer A's changes need to be removed by hand. Again the log dialog helps to track down what was moved.

本地删除，当更新时有删除进入

开发人员 A 将文件 Foo.c 改名为 Bar.c 并将其提交至版本库中。
开发人员 B 将 Foo.c 改名为 Bix.c。

更新开发人员 B 的工作副本会导致树冲突:

Bix.c 被标记为添加(包括其历史记录)。
Bar.c 被添加到工作副本中，其状态为‘正常’。
Foo.c 被标记为删除并且产生一个树冲突。

要解决这个冲突，开发人员 B 必须找出冲突的文件 Foo.c 经过改名/移动后在版本库中的新文件名是什么。可以使用日志对话框来完成这个任务。

然后，开发人员 B 需要决定 Foo.c 的新文件名中的哪一个需要保留 - 开发人员 A 改的那个还是他自己改的那个。

在开发人员 B 手工解决冲突后，使用冲突编辑对话框中的按钮将树冲突标记为已解决。

本地缺少，当合并时有更改进入

开发人员 A 在主干上工作，修改 Foo.c 并将其提交至版本库中
开发人员 B 在分支上工作，将 Foo.c 改名为 Bar.c 并将其提交至版本库中

合并开发人员 A 的主干更改到开发人员 B 的分支工作副本会导致树冲突:

Bar.c 已经存在于工作副本中，其状态为‘正常’。
Foo.c 被标记为缺少并产生树冲突。

要解决这个冲突，开发人员 B 要在冲突编辑对话框中标记文件为已解决，这样就会将其从冲突列表中删除。她接下来需要决定是否将缺少的文件 Foo.c 从版本库中复制到工作副本中，是否将开发人员 A 的对 Foo.c 的更改和合并到改名后的 Bar.c 或者是否通过标记冲突为已解决来忽略更改什么事也不做。

注意，如果你将缺少的文件从版本库中复制到工作副本中然后再标记为已解决，你复制下来的文件将被再次删除。你必须先解决冲突。

本地更改，当合并时有删除进入

开发人员 A 在主干上工作，将 Foo.c 改名为 Bar.c 并将其提交至版本库中。
开发人员 B 在分支上工作，修改 Foo.c 并将其提交至版本库中

开发人员 A 在主干上工作，将父文件夹 FooFolder 改名为 BarFolder 并将其提交至版本库中。
开发人员 B 在分支上工作，在她的工作副本中修改 Foo.c 。

合并开发人员 A 的主干更改到开发人员 B 的分支工作副本会导致树冲突:

Bar.c 被标记为添加。
Foo.c 被标记为修改并产生树冲突。

To merge her local changes with the reshuffle, Developer B must first find out to what filename the conflicted file Foo.c was renamed/moved in the repository. This can be done by using the log dialog for the merge source. The conflict editor only shows the log for the working copy as it does not know which path was used in the merge, so you will have to find that yourself. The changes must then be merged by hand as there is currently no way to automate or even simplify this process. Once the changes have been ported across, the conflicted path is redundant and can be deleted.

本地删除，当合并时有删除进入

开发人员 A 在主干上工作，将 Foo.c 改名为 Bar.c 并将其提交至版本库中。
开发人员 B 在分支上工作，将 Foo.c 改名为 Bix.c 并将其提交至版本库中

合并开发人员 A 的主干更改到开发人员 B 的分支工作副本会导致树冲突:

Bix.c 被标记为正常(未修改)状态。
Bar.c 被标记为添加(包括其历史记录)。
Foo.c 被标记为缺少并且产生树冲突。

To resolve this conflict, Developer B has to find out to what filename the conflicted file Foo.c was renamed/moved in the repository. This can be done by using the log dialog for the merge source.

然后，开发人员 B 需要决定 Foo.c 的新文件名中的哪一个需要保留 - 开发人员 A 改的那个还是他自己改的那个。

在开发人员 B 手工解决冲突后，使用冲突编辑对话框中的按钮将树冲突标记为已解决。

其它树冲突

有一些其它情况被标记为树冲突，因为冲突中卷入了文件夹而不是文件。例如你在主干和分支中添加了同名的文件夹然后在合并时就会发生树冲突。如果你想要保留合并目标中的文件夹，只要将冲突标记为已解决即可。如果你想要保留合并源中的文件夹，那么就要先使用 SVN 删除目标中的文件夹然后再合并。如果你需要处理更复杂的情况那就需要手工解决了。