<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Jan 25, 2016 at 1:54 PM Durham Goode <<a href="mailto:durham@fb.com">durham@fb.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
    <br>
    <br>
    <div>On 1/12/16 12:55 PM, Martin von
      Zweigbergk wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr"><br>
        <div class="gmail_quote">
          <div dir="ltr">On Tue, Jan 12, 2016 at 11:39 AM Augie Fackler
            <<a href="mailto:raf@durin42.com" target="_blank">raf@durin42.com</a>>
            wrote:<br>
          </div>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div style="word-wrap:break-word">
              <div>
                <blockquote type="cite">
                  <div>On Jan 12, 2016, at 13:44, Martin von Zweigbergk
                    <<a href="mailto:martinvonz@google.com" target="_blank">martinvonz@google.com</a>>
                    wrote:</div>
                  <br>
                  <div>
                    <div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
                      <div class="gmail_quote">
                        <div dir="ltr"><br>
                          On Sun, Jan 10, 2016 at 9:51 PM Martin von
                          Zweigbergk <<a href="mailto:martinvonz@google.com" target="_blank">martinvonz@google.com</a>>
                          wrote:<br>
                        </div>
                        <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">#
                          HG changeset patch<br>
                          # User Martin von Zweigbergk <<a href="mailto:martinvonz@google.com" target="_blank"></a><a href="mailto:martinvonz@google.com" target="_blank">martinvonz@google.com</a>><br>
                          # Date 1451931209 28800<br>
                          #      Mon Jan 04 10:13:29 2016 -0800<br>
                          # Node ID
                          ab1516b36e44bfb32ed6f354a9dae2f2f6300add<br>
                          # Parent 
                          4ea59d0f00be7bc44f1968c073a44274d67fa4f3<br>
                          status: change + back out == clean (API)<br>
                          <br>
                          After backing out a change, so the file
                          contents is equal to a<br>
                          previous revision of itself, we currently
                          report the status between<br>
                          the two equal revisions as modified. This is
                          because<br>
                          context._buildstatus() reports any file whose
                          new nodeid is not equal<br>
                          to _newnode as modified. That magic nodeid is
                          given only to files<br>
                          added or modified in the working directory, so
                          any file whose nodeid<br>
                          has changed between two revisions will be
                          reported as modified.<br>
                          <br>
                          Fix by simply comparing the file contents for
                          all cases where the<br>
                          nodeid changed, whether they are in the
                          working copy or committed.<br>
                        </blockquote>
                        <div><br>
                        </div>
                        <div>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.</div>
                        <div><br>
                        </div>
                        <div>Thoughts? Back out this change and accept
                          that "hg status" may report some false
                          modifications?<br>
                        </div>
                      </div>
                    </div>
                  </div>
                </blockquote>
                <div><br>
                </div>
              </div>
            </div>
            <div style="word-wrap:break-word">
              <div>
                <div>I think that's probably the least horrible result
                  sadly.</div>
              </div>
            </div>
          </blockquote>
          <div><br>
          </div>
          <div><span style="font-size:13px;line-height:19.5px">I'll send
              a patch or two soon.</span></div>
        </div>
      </div>
    </blockquote>
    <br></div><div bgcolor="#FFFFFF" text="#000000">
    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.<br>
    <br>
    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.<br></div></blockquote><div><br></div><div>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?</div></div></div>