[PATCH 4 of 4] status: change + back out == clean (API)
Martin von Zweigbergk
martinvonz at google.com
Mon Jan 25 15:59:38 CST 2016
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>
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mercurial-devel