1. 04 Nov, 2020 1 commit
  2. 23 Jun, 2020 2 commits
    • Martin von Zweigbergk's avatar
      copies: handle more cases where a file got replaced by a copy · 58e7ee23ddbd
      Martin von Zweigbergk authored
      This patch fixes the changeset-centric version in a pretty
      straight-forward way. It fixes it to automatically resolve the
      conflict, which is better than resulting in a modify/delete conflict
      as it was before b4057d001760 (merge: when rename was made on both
      sides, use ancestor as merge base, 2020-01-22).
      I'll leave it for later to test and explicitly handle cases where
      files have been renamed to the same target on different sides of the
      Differential Revision: https://phab.mercurial-scm.org/D8653
    • Martin von Zweigbergk's avatar
      tests: test more cases where a file got replaced by a copy · 4b79e92a5ef8
      Martin von Zweigbergk authored
      This adds a test where a file is modified on one branch and is renamed
      onto another file in another branch. That should ideally be
      automatically resolved (by propagating the modification to the rename
      destination). Alternatively, it could be considered a modify/delete
      conflict. It should at least not be automatically resolved by ignoring
      the modification. However, that is what actually happens with the
      changeset-centric algorithm since I broke it in b4057d001760 (merge:
      when rename was made on both sides, use ancestor as merge base,
      2020-01-22). Before that commit, it resulted in a modify/delete
      conflict. The filelog-centric algorithm was broken already before that
      Differential Revision: https://phab.mercurial-scm.org/D8652
  3. 07 Oct, 2020 2 commits
  4. 20 Oct, 2020 1 commit
  5. 29 Oct, 2020 1 commit
    • Dan Villiom Podlaski Christiansen's avatar
      commit: warn the user when a commit already exists · 976b26bdd0d8
      Dan Villiom Podlaski Christiansen authored
      Sometimes, a commit will result in an exact match of a preexisting
      commit, and if that commit isn't a branch head, hg will incorrectly
      note that it created a new head. Instead, we should warn the user that
      commit already existed in the repository.
      In practice, this bug is rather uncommon, and will only occur when the
      usr explicitly sets the date.
      Please note that this commit contains an API change to
      Differential Revision: https://phab.mercurial-scm.org/D9257
  6. 06 Oct, 2020 1 commit
    • Jörg Sonnenberger's avatar
      revlog: don't cache parsed tuples in the C module · 4404f129341e
      Jörg Sonnenberger authored
      A cached entry creates ~8 Python objects per cached changeset, which
      comes to around 200 Bytes per cached changeset on AMD64. Especially for
      operations that touch a lot of changesets, that can easily sum up to
      more than a 100MB of memory. Simple tests on large repositories show
      <2% runtime penalty for ripping out the cache, even for cache heavy
      operations like "hg log" for all revisions.
      Differential Revision: https://phab.mercurial-scm.org/D9155
  7. 16 Oct, 2020 4 commits
  8. 28 Sep, 2020 1 commit
  9. 26 Oct, 2020 1 commit
  10. 29 Oct, 2020 1 commit
  11. 02 Nov, 2020 3 commits
  12. 29 Oct, 2020 3 commits
  13. 24 Oct, 2020 1 commit
    • Matt Harbison's avatar
      repoview: only pin obsolete wdir parents while there are unresolved conflicts · 341e014fe0fb
      Matt Harbison authored
      I noticed after doing an update from an obsolete revision with a dirty wdir that
      the obsolete commit stayed visible for no obvious reason.  It was decided in
      85b03b1e4715 not to clear mergestate once all of the conflicts were resolved, in
      order to allow re-resolving.  Since the point of pinning the obsolete parents
      was to allow resolving in the first place (aaeccdb6e654), it makes sense to also
      gate it on whether or not there are any remaining files to resolve.  This might
      result in pinning again if files are marked unresolved again, but that seems
      reasonable, given that it still solves the original issue.
      Note that this isn't purely cosmetic- pushing with a pinned obsolete revision is
      likely to cause complaints about pushing multiple heads or other unexpected
      errors.  So the faster it comes out of that state, the better.
      Differential Revision: https://phab.mercurial-scm.org/D9248
      branch : stable
  14. 28 Oct, 2020 1 commit
  15. 23 Oct, 2020 2 commits
  16. 29 Oct, 2020 1 commit
  17. 22 Oct, 2020 4 commits
    • Matt Harbison's avatar
      demandimport: don't raise AttributeError if `exec_module` is missing · 8ed69bd42f10
      Matt Harbison authored
      I assume this was meant to do the check gracefully.  After shoveling a bunch of
      modules into the ignore list in order to get keyring to work out of the box on
      CentOS 8, I hit the following error accessing the password, which the change
      fixes.  Now the SecretStorage backend works out of the box, without any edits to
      the ignore list.
          ** Unknown exception encountered with possibly-broken third-party extension mercurial_keyring
          ** which supports versions unknown of Mercurial.
          ** Please disable mercurial_keyring and try your action again.
          ** If that fixes the bug please report it to https://foss.heptapod.net/mercurial/mercurial_keyring/issues
          ** Python 3.6.8 (default, Apr 16 2020, 01:36:27) [GCC 8.3.1 20191121 (Red Hat 8.3.1-5)]
          ** Mercurial Distributed SCM (version 5.5.2)
          ** Extensions loaded: evolve, topic, rebase, absorb, mercurial_keyring
          Traceback (most recent call last):
            File "/home/mharbison/hg_py...
    • Mitchell Plamann's avatar
      test: avoid bashisms in test-transaction-rollback-on-sigpipe.t · b713e4cae2d7
      Mitchell Plamann authored
      Differential Revision: https://phab.mercurial-scm.org/D9239
      branch : stable
    • Gregory Szorc's avatar
      automation: upload Python 3.9 Windows wheels · d1ce0ffdd3ce
      Gregory Szorc authored
      We are producing these. We should be publishing them.
      branch : stable
    • Gregory Szorc's avatar
      contrib: split Windows requirements into multiple files · d270b9b797a7
      Gregory Szorc authored
      Package support for Python 2 has diverged significantly. It is no
      longer trivial to maintain a single requirements file that supports
      both Python 2 and 3 because the set of packages and versions varies
      This commit split up the Windows requirements files so we have
      variants for Python 2 and 3. As part of this, I also renamed the
      files to have what I believe to be more reasonable naming ("win32"
      felt like a weird identifier to me).
      We can see that some package versions decreated on 2.7. This is
      because the old pinned versions weren't compatible with Python 2.
      branch : stable
  18. 17 Oct, 2020 2 commits
  19. 19 Oct, 2020 1 commit
  20. 20 Oct, 2020 3 commits
  21. 16 Oct, 2020 4 commits