执行 svn update 时解决合并冲突 [英] Resolving a merge conflict when I do svn update

问题描述

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

I am trying to learn basics of version control by Eric Sink - http://ericsink.com/vcbe/vcbe_usletter_lo.pdf

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

I am on page 22 now. I'll describe the scenario for you. Two users on the same computer, harry and sally are working on a file called lottery.c which is stored in a repo called lottery.

1 - Harry 提交第一个/初始代码.2 - Sally 更改并提交.3 - 当 2 发生时，harry 进行了更改，但未提交.4 - Harry 提交并出错.

1 - Harry commits the first/initial code. 2 - Sally changes it and commits. 3 - While 2 is happening, harry has made changes, but not committed. 4 - Harry commits and gets an error.

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

5 - 为了解决这个问题，harry 将使用 svn update 更新他的本地副本.

5 - To fix this, harry will update his local copy using svn update.

这是我有问题的地方！作者说输出是:

This is where I have a problem ! The author says the output is:

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:

我是新来的，我不知道如何回复这条消息.我的书错了吗?请帮我.谢谢.

I am new and I don't know how to respond to this message. Is my book wrong ? Please help me. Thanks.

推荐答案

当多人同时更改同一个文件时，他们很可能同时更改同一行.这就是发生在你身上的事情.莎莉改变了哈利改变的台词.当 Harry 执行 svn update 时，Subversion 检测到这一点，并询问您该怎么做.

When you have multiple people changing the same file at once, it's very possible for both to change the same lines. This is what happened to you. Sally changes the same lines Harry was changing. When Harry did svn update, Subversion detected this, and is asking you what to do.

警告:有时 Subversion 只是寻找您的版本与其版本之间的差异，而不是有意义的差异.例如，如果一行的缩进被改变，或者间距不同，或者如果你改变了行尾，Subversion 会将此声明为冲突，即使它可能不是.这也许是这本书没有发现这个问题的原因，但你找到了.不代表你做错了什么.

A word of warning: Sometimes Subversion is only looking for differences in a line between your version and their version, and not meaningful differences. For example, if the indentation of a line was changed, or spacing was different, or if you changed the line endings, Subversion will declare this as a conflict even though it probably isn't. This maybe why the book didn't find this issue, but you did. Doesn't mean you did anything wrong.

怎么办?Subversion 为您提供了一些选择.

What to do? Subversion is giving you a few choices.

• 推迟 p:对于这种情况，我通常会这样做.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(Sally 所做的)与您所做的更改(Harry 的更改)中的更改.通常，更改很小，很容易弄清楚要做什么.

This is showing you the changes in revision rxxx (what Sally did) look like vs. the changes you have (Harry's changes). Usually, the changes are minor enough that it's pretty easy to figure out what to do.

• show diff df:这将显示您的更改(Harry 的)与其他修订版(Sally 的)之间的差异.它基本上会向您显示差异标记.
• edit e:您可以在进行合并时编辑合并冲突，而不必等到以后再进行.
• merge m:不太清楚这是做什么的.您现在正在进行合并，所以这没有太大意义.
• 他们冲突的一面 tc:接受 Sally 为解决冲突所做的事情.您可能需要重做更改，但至少您正在考虑 Sally 的更改.
• 我的冲突一方 mc:最危险的情况，因为你完全无视 Sally 的变化.Sally 进行了修复，而您可能正在取消修复它.当版本发布时，Sally 的修复程序不在其中，您将因删除更改而受到指责.那么，你为什么要这样做?因为你已经看到了这些变化，并意识到冲突真的不是什么冲突.这是缩进或类似的变化.或者，您将变量称为 increment，而 Sally 将其称为 counter.

• 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.

正如我所说，我通常会推迟，让我的更新完成，然后处理问题.

As I said, I usually do a postpone, let my update finish, then handle the problems.

一旦你解决了这个问题，你就会对该文件执行一个 svn 解决，让 Subversion 知道你已经解决了这个冲突.

Once you fix the problem, you do a svn resolved on that file to let Subversion know you've fixed the conflict.

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

There are further choices -- for example, you can launch a third party diff/merge tool to handle the conflict.

有关更多信息，请查看关于 解决合并冲突.

For more information, take a look at the Subversion on line manual about resolving merge conflicts.

这篇关于执行 svn update 时解决合并冲突的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！