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

[Augie Fackler]

> 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 <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.

> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com <mailto:Mercurial-devel at selenic.com>
> https://selenic.com/mailman/listinfo/mercurial-devel <https://selenic.com/mailman/listinfo/mercurial-devel>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20160112/15928515/attachment.html>