[PATCH 4 of 4] status: change + back out == clean (API)

[Martin von Zweigbergk]

On Tue, Jan 12, 2016 at 10:44 AM Martin von Zweigbergk <
martinvonz at google.com> wrote:

> On Sun, Jan 10, 2016 at 9:51 PM Martin von Zweigbergk <
> martinvonz at google.com> wrote:
>
>> # HG changeset patch
>> # User Martin von Zweigbergk <martinvonz at google.com>
>> # Date 1451931209 28800
>> #      Mon Jan 04 10:13:29 2016 -0800
>> # Node ID ab1516b36e44bfb32ed6f354a9dae2f2f6300add
>> # Parent  4ea59d0f00be7bc44f1968c073a44274d67fa4f3
>> status: change + back out == clean (API)
>>
>> After backing out a change, so the file contents is equal to a
>> previous revision of itself, we currently report the status between
>> the two equal revisions as modified. This is because
>> context._buildstatus() reports any file whose new nodeid is not equal
>> to _newnode as modified. That magic nodeid is given only to files
>> added or modified in the working directory, so any file whose nodeid
>> has changed between two revisions will be reported as modified.
>>
>> Fix by simply comparing the file contents for all cases where the
>> nodeid changed, whether they are in the working copy or committed.
>>
>
> I didn't check the performance impact of this until now, sorry :-( Since
> we used to assume that different nodeid implied different contents (and
> thus reported some clean files as modified), we avoided a lot of content
> comparisons. Bad cases like "hg st --rev .~1000 --rev ." on the mozilla
> repo (>7k files) goes from <1s to >30s.
>

I should have said that that is with "somewhat cold disk cache" (I'm not
allowed to clear caches on my machine even as sudo). With warm disk, it
goes from 0.4s to 1.4s.


>
> Thoughts? Back out this change and accept that "hg status" may report some
> false modifications?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20160112/77729453/attachment.html>