Hg:逐行更新?
我有一个错误存在于一个变更集中,但不存在于其父变更集中。 Mercurial 中是否有一些功能可以让我以较小的增量“更新”,以查看问题从哪里开始?
例如,如果差异是函数 A、B 和 C 中的更改,我将在进行每个更改后运行测试套件,以尝试诊断问题。
I have a bug that is present in one changeset but not its parent. Is there some functionality in mercurial where I can "update" in smaller increments, to see where the problem starts?
For example, if the diff is a change in functions A, B, and C, I would run the test suite after making each of those changes, to try to diagnose the problem.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
答案是:这取决于你愿意投入多少体力劳动。
你能做的就是卷起袖子,以交互模式使用阁楼扩展。如果您正在使用 TortoiseHg,那么您已经拥有了它,只需运行
hgtk shelve
,它就可以让您一次围绕一个差异块移动更改。 (块是一组连续的行差异)还有许多其他差异修补工具可以为您提供单块分辨率。如果您需要更多详细信息,请告诉我。
为了好玩,我们来谈谈像 bisect 这样的自动化解决方案是如何不可能实现的,因为半个变更集仍然应该编译并不总是有意义的。更糟糕的是,如果它们确实编译了,但存在逻辑错误怎么办?这是一个简单的最坏情况……
The answer is: it depends how much manual labor you are willing to put in.
What you can do is roll up your sleeves and use the attic extension in interactive mode. If you are using TortoiseHg, you already have it, just run
hgtk shelve
and it lets you move changes around one diff hunk at a time. (a hunk being a set of contiguous line diffs)There are plenty of other diff patching tools that will give you single-hunk resolution. Let me know if you need more details.
And just for fun, let's talk about how an automated solution like
bisect
is not possible, since it doesn't always make sense that half a changeset should still compile. Even worse, what if they do compile, but have logic errors? Here's a simple worst case scenario...您可以使用 hg diff -r firstrev -r secondaryrev 并将输出过滤为仅与这些函数相关的位,然后逐个逐步执行补丁。
或者您可以使用为此目的而设计的 bisect 扩展 - 尽管它会为您提供对代码库所做的所有更改,而不仅仅是涉及特定功能的更改。您可以通过仅提取更改功能的转速然后仅对这些修订进行二分搜索来改善此问题。
You can use
hg diff -r firstrev -r secondrev
and filter the output to only the bits concerning those functions, then step through the patches one by one.Or you could use the bisect extension, designed for this purpose - although it will give you all changes made to your codebase, not just those concerning a particular function. You could ameliorate this by extraction only the revs changing your function and then doing a bisection search of those revisions only.