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

[Durham Goode]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20160125/d9f6b6f6/attachment.html>