解决 svn update 时的合并冲突

我正在尝试学习 Eric Sink 的版本控制基础知识 -http://ericsink.com/vcbe/vcbe_usletter_lo.pdf http://ericsink.com/vcbe/vcbe_usletter_lo.pdf

我现在在第22页。我将为你描述一下这个场景。同一台计算机上的两个用户 harry 和 sally 正在处理一个名为 lottery.c 的文件，该文件存储在名为 lottery 的存储库中。

1 - Harry 提交第一个/初始代码。 2 - Sally 更改并提交。 3 - 当 2 发生时，哈利做出了改变，但没有承诺。 4 - Harry 提交并得到一个错误。

Transmitting file data .svn: Commit failed (details follow):
svn: File '/lottery.c' is out of date

5 - 为了解决这个问题，哈利将使用以下命令更新他的本地副本svn update.

这就是我遇到问题的地方！作者说输出是：

lottery harry$ svn update
G lottery.c
Updated to revision 2.

但是，我的输出是：

lottery harry$ svn update
Updating '.':
C    lottery.c
Updated to revision 2.
Conflict discovered in file 'lottery.c'.
Select: (p) postpone, (df) show diff, (e) edit file, (m) merge,
        (mc) my side of conflict, (tc) their side of conflict,
        (s) show all options:

我是新人，不知道如何回复这个消息。我的书有错吗？请帮我。谢谢。

当多人同时更改同一个文件时，两个人很可能都更改相同的行。这就是发生在你身上的事。莎莉改变了哈利改变的同样的台词。当哈利这么做的时候svn update，Subversion 检测到此情况，并询问您该怎么做。

警告：有时 Subversion 只寻找你的版本和他们的版本之间的一行差异，而不是有意义的差异。例如，如果行的缩进发生更改，或间距不同，或者更改了行结尾，Subversion 会将其声明为冲突，即使它可能不是。这也许是为什么这本书没有发现这个问题，但你却发现了。并不意味着你做错了什么。

该怎么办？ Subversion 为您提供了一些选择。

• postpone p: This is what I usually do with this type of situation. Subversion will embed in the file diff markers that look like this in the file:

<<<<<<< .mine
foobar
=======
fubar
>>>>>>> .rxxx

这向您展示了修订版 rxxx 中的更改（莎莉所做的）与您所做的更改（哈利的更改）的情况。通常，这些变化都很小，所以很容易弄清楚该怎么做。

• show diff df: This will show you the differences between your changes (Harry's) and what's in the other revision (Sally's). It basically shows you the diff markers.
• edit e: You can edit the merge conflict as you do the merge instead of waiting till later.
• merge m: Not too sure what this does. You're doing the merge right now, so this doesn't make too much sense.
• their side of conflict tc: Accept what Sally did in order to resolve the conflict. You probably have to redo your changes, but at least you're considering Sally's changes.
• my side of the conflict mc: The most dangerous scenario because you're completely ignoring Sally's changes. Sally did a fix, and you're possibly unfixing it. When the release comes out, and Sally's fix isn't in it, you will be blamed for removing the change. So, why do you do this? Because you already looked at the changes, and realized the conflict really wasn't much of a conflict. It was a change in indentation or something similar. Or you called a variable increment and Sally called it counter.

正如我所说，我通常会做一个postpone，让我的更新完成，然后处理问题。

一旦你解决了问题，你就做一个svn resolved对该文件进行编辑，让 Subversion 知道您已经解决了冲突。

还有更多选择 - 例如，您可以启动第三方差异/合并工具来处理冲突。

有关详细信息，请参阅 Subversion 在线手册：解决合并冲突 http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.tour.cycle.resolve.