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

[Martin von Zweigbergk]

On Mon, Jan 25, 2016 at 1:54 PM Durham Goode <durham at fb.com> wrote:

>
>
> On 1/12/16 12:55 PM, Martin von Zweigbergk wrote:
>
>
> 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>
>>> 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.
>
>
> The perf consequence of this change is a bit disappointing.  It also
> affects remotefilelog repos, since previously we would be able to compute
> status based almost entirely on the manifest contents, but now we need the
> before and after file contents of every file.
>
> Was this actively breaking something before?  I can change remotefilelog's
> implementation of filelog.cmp to return False if the nodes are different,
> but I'd rather not diverge from core like that if possible.
>

>From reading your reply, it seems like you did not see that I backed out
this change (54522bbe1597). Did you cut a release between this patch and
the backout?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-devel/attachments/20160125/cc6a77bf/attachment-0002.html>