当我执行 svn update 时解决合并冲突
Resolving a merge conflict when I do svn update
我正在尝试学习 Eric Sink 的版本控制基础知识 - http://ericsink.com/vcbe/vcbe_usletter_lo.pdf
我现在在第 22 页。我会为你描述这个场景。同一台计算机上的两个用户 harry 和 sally 正在处理一个名为 lottery.c 的文件，该文件存储在一个名为 lottery 的存储库中。
1 - Harry 提交了 first/initial 代码。
2 - Sally 更改并提交。
3 - 当 2 发生时，harry 进行了更改，但没有提交。
4 - Harry 提交并收到错误。
Transmitting file data .svn: Commit failed (details follow):
svn: File '/lottery.c' is out of date
5 - 要解决此问题，harry 将使用 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:
我是新来的，不知道如何回复这条消息。我的书错了吗？请帮我。谢谢。
"G"表示该文件被其他人修改过，但是那个人所做的修改是在文件的不同部分，所以SVN可以在不寻求帮助的情况下为您合并。
"C"表示不仅是别人修改了文件，而且他们修改的是你修改的同一行，所以SVN不知如何是好。现在由您进行合并。
你可能没有做错任何事，这本书也没有错，显然他们只是遗漏了具体变化的细节。
当多人同时更改同一个文件时，很可能两人都更改了相同的行。这就是发生在你身上的事。 Sally 更改的台词与 Harry 更改的台词相同。当 Harry svn update 时，Subversion 检测到这一点，并询问您该怎么做。
一句警告：有时 Subversion 只是寻找你的版本和他们的版本之间的差异，而不是有意义的差异。例如，如果一行的缩进改变了，或者间距不同了，或者如果你改变了行尾，Subversion 会声明这是一个冲突，即使它可能不是。这也许就是为什么这本书没有找到这个问题，但你找到了。并不代表你做错了什么。
怎么办？ Subversion 为您提供了一些选择。
- postpone p: 这就是我通常遇到这种情况的做法。 Subversion 将嵌入文件 diff markers，在文件中看起来像这样：
<<<<<<< .mine
foobar
=======
fubar
>>>>>>> .rxxx
这向您展示了修订版 rxxx（Sally 所做的）与您所做的更改（Harry 的更改）的对比。通常，更改很小，很容易弄清楚要做什么。
- show diff df：这将显示您的更改（Harry 的）与其他修订版（Sally 的）之间的差异.它基本上向您展示了差异标记。
- edit e：您可以在合并时编辑合并冲突，而不是等到以后。
- merge m：不太确定这是做什么的。您现在正在进行合并，所以这没有太大意义。
- 他们一方的冲突 tc：接受莎莉为了解决冲突所做的一切。您可能必须重做您的更改，但至少您正在考虑 Sally 的更改。
- 我方冲突 mc: 最危险的场景，因为你完全无视了Sally的变化。 Sally 进行了修复，而您可能正在取消修复。当发行版发布时，Sally 的修复程序不在其中，您将因删除更改而受到指责。那么，你为什么要这样做？因为您已经查看了更改，并意识到冲突实际上并没有太大的冲突。这是缩进或类似的变化。或者您将一个变量命名为
increment 而 Sally 将其命名为 counter.
正如我所说，我通常会推迟，让我的更新完成，然后再处理问题。
一旦你解决了这个问题，你就在那个文件上做一个 svn resolved 让 Subversion 知道你已经解决了冲突。
还有更多选择 -- 例如，您可以启动第三方 diff/merge 工具来处理冲突。
有关详细信息，请查看有关 resolving merge conflicts 的 Subversion 联机手册。
如果您 select s 选项，它将显示：
(e) edit - change merged file in an editor
(df) diff-full - show all changes made to merged file
(r) resolved - accept merged version of file
(dc) display-conflict - show all conflicts (ignoring merged version)
(mc) mine-conflict - accept my version for all conflicts (same)
(tc) theirs-conflict - accept their version for all conflicts (same)
(mf) mine-full - accept my version of entire file (even non-conflicts)
(tf) theirs-full - accept their version of entire file (same)
(p) postpone - mark the conflict to be resolved later
(l) launch - launch external tool to resolve conflict
(s) show all - show this list
使用 dc 查看冲突，然后您可以决定使用的最佳选项
我正在尝试学习 Eric Sink 的版本控制基础知识 - http://ericsink.com/vcbe/vcbe_usletter_lo.pdf
我现在在第 22 页。我会为你描述这个场景。同一台计算机上的两个用户 harry 和 sally 正在处理一个名为 lottery.c 的文件，该文件存储在一个名为 lottery 的存储库中。
1 - Harry 提交了 first/initial 代码。 2 - Sally 更改并提交。 3 - 当 2 发生时，harry 进行了更改，但没有提交。 4 - Harry 提交并收到错误。
Transmitting file data .svn: Commit failed (details follow):
svn: File '/lottery.c' is out of date
5 - 要解决此问题，harry 将使用 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:
我是新来的，不知道如何回复这条消息。我的书错了吗？请帮我。谢谢。
"G"表示该文件被其他人修改过，但是那个人所做的修改是在文件的不同部分，所以SVN可以在不寻求帮助的情况下为您合并。
"C"表示不仅是别人修改了文件，而且他们修改的是你修改的同一行，所以SVN不知如何是好。现在由您进行合并。
你可能没有做错任何事，这本书也没有错，显然他们只是遗漏了具体变化的细节。
当多人同时更改同一个文件时，很可能两人都更改了相同的行。这就是发生在你身上的事。 Sally 更改的台词与 Harry 更改的台词相同。当 Harry svn update 时，Subversion 检测到这一点，并询问您该怎么做。
一句警告：有时 Subversion 只是寻找你的版本和他们的版本之间的差异，而不是有意义的差异。例如，如果一行的缩进改变了，或者间距不同了，或者如果你改变了行尾，Subversion 会声明这是一个冲突，即使它可能不是。这也许就是为什么这本书没有找到这个问题，但你找到了。并不代表你做错了什么。
怎么办？ Subversion 为您提供了一些选择。
- postpone p: 这就是我通常遇到这种情况的做法。 Subversion 将嵌入文件 diff markers，在文件中看起来像这样：
<<<<<<< .mine
foobar
=======
fubar
>>>>>>> .rxxx
这向您展示了修订版 rxxx（Sally 所做的）与您所做的更改（Harry 的更改）的对比。通常，更改很小，很容易弄清楚要做什么。
- show diff df：这将显示您的更改（Harry 的）与其他修订版（Sally 的）之间的差异.它基本上向您展示了差异标记。
- edit e：您可以在合并时编辑合并冲突，而不是等到以后。
- merge m：不太确定这是做什么的。您现在正在进行合并，所以这没有太大意义。
- 他们一方的冲突 tc：接受莎莉为了解决冲突所做的一切。您可能必须重做您的更改，但至少您正在考虑 Sally 的更改。
- 我方冲突 mc: 最危险的场景，因为你完全无视了Sally的变化。 Sally 进行了修复，而您可能正在取消修复。当发行版发布时，Sally 的修复程序不在其中，您将因删除更改而受到指责。那么，你为什么要这样做？因为您已经查看了更改，并意识到冲突实际上并没有太大的冲突。这是缩进或类似的变化。或者您将一个变量命名为
increment而 Sally 将其命名为counter.
正如我所说，我通常会推迟，让我的更新完成，然后再处理问题。
一旦你解决了这个问题，你就在那个文件上做一个 svn resolved 让 Subversion 知道你已经解决了冲突。
还有更多选择 -- 例如，您可以启动第三方 diff/merge 工具来处理冲突。
有关详细信息，请查看有关 resolving merge conflicts 的 Subversion 联机手册。
如果您 select s 选项，它将显示：
(e) edit - change merged file in an editor
(df) diff-full - show all changes made to merged file
(r) resolved - accept merged version of file
(dc) display-conflict - show all conflicts (ignoring merged version)
(mc) mine-conflict - accept my version for all conflicts (same)
(tc) theirs-conflict - accept their version for all conflicts (same)
(mf) mine-full - accept my version of entire file (even non-conflicts)
(tf) theirs-full - accept their version of entire file (same)
(p) postpone - mark the conflict to be resolved later
(l) launch - launch external tool to resolve conflict
(s) show all - show this list
使用 dc 查看冲突，然后您可以决定使用的最佳选项