SVN产生树冲突的几种情形

当一名开发人员移动、重命名、删除一个文件或文件夹,而另一名开发人员也对它们进行了移动、重命名、删除或者仅仅是修改时就会发生树冲突。有很多种不同的情形可以导致树冲突,而且不同的情形需要不同的步骤来解决冲突。

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

1、开发人员 A 修改 Foo.c 并将其提交至版本库中。

2、开发人员 B 同时在他的工作副本中将文件 Foo.c 改名为 Bar.c,或者仅仅是删除了 Foo.c 或它的父文件夹。

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

A、在工作副本中,Foo.c 被删除了,但是被标记为树冲突。

B、如果冲突是由于更改文件名引起的而不是删除文件引起的,那么 Bar.c 被标记为添加,但是其中却不包括开发人员 A 修改的内容。

开发人员 B 现在必须做出选择是否保留开发人员 A 的更改。在更改文件名的案例中,他可以将 Foo.c 的更改合并到改名后的文件 Bar.c 中去。对于删除文件或文件夹的案例中,他可以选择保留包含开发人员 A 更改内容的项目并放弃删除操作。或什么也不做而直接将冲突标记为已解决,那样他实际上丢弃了开发人员 A 的更改。

如果 TortoiseSVN 能够找到被改名为 Bar.c 的原始文件,冲突编辑对话框将可以合并更改。这取决于在什么地方调用更新操作,它也许不能找到原始文件。

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

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

2、开发人员 B 在他的工作副本中修改文件 Foo.c。

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

1、开发人员 A 将父文件夹 FooFolder 改名为 BarFolder 并将其提交至版本库中。

2、开发人员 B 在他的工作副本中修改文件 Foo.c。

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

A、Bar.c 被当作一个正常文件添加到工作副本中。

B、Foo.c 被标记为添加(包括其历史记录)并且产生树冲突。

对于一个文件夹冲突:

A、BarFolder 被当作一个正常文件夹添加到工作副本中。

B、FooFolder 被标记为添加(包括其历史记录)并且产生树冲突。

Foo.c 被标记为已修改。

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

要合并她的本机更改到新布局中,开发人员 B 必须先找出冲突的文件 Foo.c 经过改名/移动后在版本库中的新文件名是什么。可以使用日志对话框来完成这个任务。更改必须要手工合并,因为没有办法自动的或者简单的完成此操作。一旦更改移植完毕,冲突的路径就是多余的并且可以删除。在此案例中,使用冲突编辑对话框中的删除按钮进行清理并将冲突标记为已解决。

如果开发人员 B 认为 A 的更改是错误的,那么在冲突编辑对话框中她必须选择保留按钮。这样就会标记冲突的文件/文件夹为已解决,但是需要手工删除开发人员 A 的更改。又是通过日志对话框帮助追踪哪些文件移动了。

本地删除,当更新时有删除进入
1、开发人员 A 将文件 Foo.c 改名为 Bar.c 并将其提交至版本库中。

2、开发人员 B 将 Foo.c 改名为 Bix.c。

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

A、Bix.c 被标记为添加(包括其历史记录)。

B、Bar.c 被添加到工作副本中,其状态为‘正常’。

C、Foo.c 被标记为删除并且产生一个树冲突。

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

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

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

本地缺少,当合并时有更改进入
1、开发人员 A 在主干上工作,修改 Foo.c 并将其提交至版本库中

2、开发人员 B 在分支上工作,将 Foo.c 改名为 Bar.c 并将其提交至版本库中

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

A、Bar.c 已经存在于工作副本中,其状态为‘正常’。

B、Foo.c 被标记为缺少并产生树冲突。

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

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

本地更改,当合并时有删除进入
1、开发人员 A 在主干上工作,将 Foo.c 改名为 Bar.c 并将其提交至版本库中。

2、开发人员 B 在分支上工作,修改 Foo.c 并将其提交至版本库中

当文件夹改名时有类似的案例,但是在 Subversion 1.6 中还未被识别…

1、开发人员 A 在主干上工作,将父文件夹 FooFolder 改名为 BarFolder 并将其提交至版本库中。

2、开发人员 B 在分支上工作,在她的工作副本中修改 Foo.c 。

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

A、Bar.c 被标记为添加。

B、Foo.c 被标记为修改并产生树冲突。

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

要合并她的本机更改到新布局中,开发人员 B 必须先找出冲突的文件 Foo.c 经过改名/移动后在版本库中的新文件名是什么。可以通过适用于合并源码的日志对话框来完成这个任务。冲突编辑器仅显示工作副本的日志因为它不知道将哪个路径的更改合并进来,所以你需要自己找到它。更改必须要手工合并,因为没有办法自动的或者简单的完成此操作。一旦更改移植完毕,冲突的路径就是多余的并且可以删除。在此案例中,使用冲突编辑对话框中的删除按钮进行清理并将冲突标记为已解决。

如果开发人员 B 认为 A 的更改是错误的,那么在冲突编辑对话框中她必须选择保留按钮。这样就会标记冲突的文件/文件夹为已解决,但是需要手工删除开发人员 A 的更改。又是通过日志对话框帮助追踪哪些文件移动了。

本地删除,当合并时有删除进入
1、开发人员 A 在主干上工作,将 Foo.c 改名为 Bar.c 并将其提交至版本库中。

2、开发人员 B 在分支上工作,将 Foo.c 改名为 Bix.c 并将其提交至版本库中

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

A、Bix.c 被标记为正常(未修改)状态。

B、Bar.c 被标记为添加(包括其历史记录)。

C、Foo.c 被标记为缺少并且产生树冲突。

要解决这个冲突,开发人员 B 必须先找出冲突的文件 Foo.c 经过改名/移动后在版本库中的新文件名是什么。可以通过适用于合并源码的日志对话框来完成这个任务。冲突编辑器仅显示工作副本的日志因为它不知道将哪个路径的更改合并进来,所以你需要自己找到它。

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

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

其它树冲突

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

截取自:http://tortoisesvn.net/docs/nightly/TortoiseSVN_zh_CN/

这篇文章目前有3条评论

  1. heroicYang 2012-03-14 20:51

    这个必须Mark收藏,你用Git还是?

    沙发王 !
  2. 番茄 2012-03-21 23:47

    技术文章,看不懂。

    板凳党 !
Leave a Reply

(必填项)

(必填项)

(可选)