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

[Durham Goode]

On 1/25/16 1:59 PM, Martin von Zweigbergk wrote:
>
>
> On Mon, Jan 25, 2016 at 1:54 PM Durham Goode <durham at fb.com 
> <mailto: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
>>     <mailto:raf at durin42.com>> wrote:
>>
>>>         On Jan 12, 2016, at 13:44, Martin von Zweigbergk
>>>         <martinvonz at google.com <mailto:martinvonz at google.com>> wrote:
>>>
>>>
>>>         On Sun, Jan 10, 2016 at 9:51 PM Martin von Zweigbergk
>>>         <martinvonz at google.com <mailto:martinvonz at google.com>> wrote:
>>>
>>>             # HG changeset patch
>>>             # User Martin von Zweigbergk <martinvonz at google.com
>>>             <mailto: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?
Ah, ok.  I misread your final message about sending a patch or two 
soon.  Yes, we cut a branch and that's what I'm testing.  I'll 
cherry-pick in the fix.  Thanks for pointing that out.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20160125/0f8c6271/attachment.html>