Skip to content
Snippets Groups Projects
  1. Sep 08, 2019
    • Pierre-Yves David's avatar
      changegroup: move message about added changes to transaction summary · d7304434
      Pierre-Yves David authored
      Before that, applying multiple changegroups in the same transaction issued the
      message multiple time. This result in a confusing output:
      
          adding changesets
          adding manifests
          adding file changes
          added 32768 changesets with 60829 changes to 2668 files
          adding changesets
          adding manifests
          adding file changes
          added 8192 changesets with 16885 changes to 1553 files
          adding changesets
          adding manifests
          adding file changes
          added 1020 changesets with 1799 changes to 536 files
          adding changesets
          adding manifests
          ...
      
      Instead, we now only issue the message once at the end of the transaction,
      summing up all added changesets, changes and files. The line is identical, but
      happens sightly later in the output.
      
      There are other suboptimal behavior around issue multiple changegroup (eg:
      progress bar). We'll cover them later.
      
      This impact of lot of test as one would expect, but a two pass check show they
      are just the order change we expected.
      
      To deal with "under the hood" bundle application by internal code, we had to
      take a slightly hacky move. We could clean that up with a more official way to
      enter "under the hood" section, however I want to keep this series simple to get
      it landed. This kind of change have a very high bit rot rate since it impact a
      lot of test output.
      d7304434
  2. Sep 07, 2019
  3. Oct 14, 2018
    • Pierre-Yves David's avatar
      transaction: issue "new obsmarkers" message at the end of the transaction · 38392d5b
      Pierre-Yves David authored
      Instead of making bundle2 code responsible for this, it seems better to have it
      handled and the transaction level. First, it means the message will be more
      consistently printed. Second it means we won't spam the message over and over if
      the data arrive in multiple piece. Third, we are planning to move other similar
      message at the same level (for the same reason) so having them all at the same
      location will help us to control the order they are displayed.
      38392d5b
    • Pierre-Yves David's avatar
      debugobsolete: also issue the "new obsmarkers" messsage · 34a46d48
      Pierre-Yves David authored
      We are going to improve the way this message is issued in the core codebase.
      This will make it appears for `hg debugobsolete` too. Since this seems like a
      good idea, we make the output change in a previous changesets to clarify the
      next changeset.
      34a46d48
  4. Sep 05, 2019
  5. Sep 08, 2019
  6. Apr 27, 2019
    • Pierre-Yves David's avatar
      discovery: replace "heads" by "changesets" in a output note (BC) · 775224e2
      Pierre-Yves David authored
      When using `hg push --rev X`, the subset considered by discovery is only `::X`.
      In addition, `X` can be any local revisions not just local heads. As a result
      the message "all local heads known locally" can be misleading. We replace it
      with the more accurate "all local changesets known remotely".
      
      The message appears when in verbose not, so this is stricly speaking a BC
      breakage. I am not sure this would be a real issue in practice...
      775224e2
  7. Sep 05, 2019
  8. Sep 07, 2019
  9. Sep 02, 2019
  10. Aug 30, 2019
  11. Aug 08, 2019
  12. Aug 07, 2019
  13. Sep 07, 2019
  14. Aug 07, 2019
  15. Sep 07, 2019
  16. Jun 14, 2019
  17. Aug 26, 2019
  18. Jul 17, 2019
    • Martin von Zweigbergk's avatar
      copies: remove existing copy info from the changeset on amend (BC) · 57ea0a81
      Martin von Zweigbergk authored
      When amending a changeset with copy information in the changeset and
      the new changeset doesn't have any copy information (or similar for
      "filesadded" and "filesremoved"), we shouldn't keep it.
      
      A drawback of this is that we now unconditionally remove these four
      entries from the extras, breaking any extensions that happened to
      write entries with the same names (which seems very unlikely).
      
      I think I'd heard that there was list of blacklisted keys that would
      be removed from the extras when a commit is rewritten, but I couldn't
      find that. It would make sense to add the keys mentioned above there
      instead of the custom filtering I've added in this patch.
      
      Differential Revision: https://phab.mercurial-scm.org/D6752
      57ea0a81
    • Martin von Zweigbergk's avatar
      tests: show invalid copies when turning off copies-in-changeset · 6f027355
      Martin von Zweigbergk authored
      If you turn on copies in changesets and write a commit with a copy,
      then turn it off and amend the commit while undoing the copy, the
      invalid copy information will remain. The read path doesn't crash in
      invalid copy data, but it seems better to not produce the invalid
      data.
      
      Differential Revision: https://phab.mercurial-scm.org/D6751
      6f027355
  19. Aug 19, 2019
Loading