gpt4 book ai didi

mercurial - 在 Mercurial 中,一条线如何在没有 merge 的情况下消失?

转载 作者:行者123 更新时间:2023-12-02 08:50:02 24 4
gpt4 key购买 nike

使用 mercurial,我遇到了一个奇怪的问题,一位提交者的一行在时间线的某个时刻消失了,我无法解释为什么会这样。

日志看起来像这样:

changeset:   172:xyz123
parent: 76:pqr345
user: barry baggings
date: Mon Jan 16 0:12:43 2012 +0000
summary: blah blah blah

changeset: 171:opq123
parent: 165:abc234
user: mary moggings
date: Mon Feb 01 1:12:41 2012 +0000
summary: naw naw naw

运行:hg diff -r 171 -r 172 为 abc.py 提供此信息(省略标题):

print "context line1"
- print "i need this line!"
print "context line2"

有问题的 mod print "i need this line! 肯定是在 171:opq123 中引入的,但在 172:xyz123 中又消失了,

但是 76 和 172 之间的差异显示没有对 abc.py 的修改! Barry 怎么能超越 Mary 这样的变化?

我是不是误解了这一切是如何运作的?我在 CVS 和 SVN 等方面有相当不错的背景,但 DVCS 有时会让我头疼……有人可以解释一下吗?

我有点怀疑这是因为我们使用的是 mercurial 1.7.1 - 这可能是一个错误吗?

最佳答案

这些是不同的头,172 不是基于 171。该图是在启用 graphlog 扩展并运行 hg glog 时生成的,或者在运行时可以从 hgweb 中直观地看到hg serve,在浏览器中打开它并单击“图形”链接,显示它可能比变更集的“父”值更清楚。

o    changeset:   172:xyz123
| parent: 76:pqr345
| user: barry baggings
| date: Mon Jan 16 0:12:43 2012 +0000
| summary: blah blah blah
|
| o changeset: 171:opq123
| | parent: 165:abc234
| | user: mary moggings
| | date: Mon Feb 01 1:12:41 2012 +0000
| | summary: naw naw naw
| |

这清楚地表明变更集 172 不是基于变更集 171。因此在比较它们时,变更可能发生在其他地方。您不是在比较祖先和后代,而是在某种程度上比较表亲。

因此,虽然您在 171 中引入了它,但由于 172 不是基于 171,因此它没有添加该行。 merge 实际上是您获取变更所需要的,以创建基于 171 和 172(以及它们的祖先,直到它们收敛)的变更集。

您可能有更多想要 merge 的头像;你可以使用 hg heads 来查看它们。 hg serve 也有助于理解此类内容。

关于mercurial - 在 Mercurial 中,一条线如何在没有 merge 的情况下消失?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/9175719/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com