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

[Martin von Zweigbergk]

On Tue, Jan 12, 2016 at 11:39 AM Augie Fackler <raf at durin42.com> wrote:

> On Jan 12, 2016, at 13:44, 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.
>
> Thoughts? Back out this change and accept that "hg status" may report some
> false modifications?
>
>
> I think that's probably the least horrible result sadly.
>

I'll send a patch or two soon.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20160112/d586829e/attachment.html>