[PATCH 4 of 4] status: change + back out == clean (API)
Durham Goode
durham at fb.com
Mon Jan 25 16:19:38 CST 2016
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>
More information about the Mercurial-devel
mailing list