Skip to content
Snippets Groups Projects

10.3.0 compat branches

Merged Raphaël Gomès requested to merge topic/mercurial-4.6/release-prep into branch/mercurial-4.6
  1. Mar 11, 2021
  2. Mar 09, 2021
  3. Feb 24, 2021
  4. Feb 12, 2021
  5. Feb 03, 2021
  6. Feb 08, 2021
  7. Feb 01, 2021
  8. Mar 03, 2021
    • Anton Shestakov's avatar
      tests: remove some unnecessary config · a1dad44f
      Anton Shestakov authored
      Some of these tests were originally split from a single file that had (and
      used) these options, and some of the tests were later created by just
      mindlessly copypasting the same set of options that aren't applicable to the
      newly written tests.
      
      Things removed by this patch:
      
      - web section from tests that don't use hg serve and don't push
      - phases.publish from tests that don't exchange changesets between repos
      - diff section from tests that don't have any diffs
      - defaults section that sets the date
      
      The defaults section that only adds -d '0 0' to commands should no longer be
      necessary because run-tests.py sets devel.default-date='0 0' since 4.3, and all
      command in evolve should respect this config option.
      a1dad44f
  9. Mar 04, 2021
  10. Mar 03, 2021
  11. Feb 01, 2021
  12. Jan 31, 2021
  13. Sep 05, 2020
  14. Aug 26, 2020
  15. Mar 01, 2021
  16. Feb 27, 2021
  17. Feb 23, 2021
  18. Dec 22, 2020
  19. Feb 17, 2021
  20. Feb 22, 2021
  21. Feb 23, 2021
    • Kyle Lippincott's avatar
      obslog: correct help to state that obslog is the command name · bf74edda
      Kyle Lippincott authored
      Right now, `hg help obslog` says the following, which is a bit confusing:
      
      ```
      hg olog [OPTION]... [[-r] REV]...
      
      aliases: olog
      ```
      
      Since the primary command name is determined by the order the commands are
      defined in, and we use 'obslog' as the name for the pager, I've chosen
      `hg obslog` as the canonical name and am only adjusting the help string.
      bf74edda
  22. Feb 22, 2021
  23. Feb 17, 2021
  24. Feb 22, 2021
  25. Jan 24, 2021
    • Pierre-Yves David's avatar
      divergence-resolution: [patch 3] fix a messed up test case · 961a940a
      Pierre-Yves David authored
      Because of logic change in divergence resolution which causes the order change
      in picking the resolution parent this test case was messed up.
      
      It was supposed to test that it hits merge conflict while merging the
      two divergent csets but because of some change in previous patches, we hit
      conflict early during relocation of one of the cset.
      
      This patch, by resolving the conflict for relocation make sure that we test
      the conflict while merging the two divergent csets.
      961a940a
    • Pierre-Yves David's avatar
      divergence-resolution: [patch 2] fix a messed up test case · 32c0b289
      Pierre-Yves David authored
      Because of logic change in divergence resolution which causes the order change
      in picking the resolution parent this test case was messed up.
      
      It was supposed to test that that it hits conflict while relocating the
      divergent cset but because of some change in previous patches, relocation went
      successful and it hits conflict while merging the two divergent csets.
      
      This patch, by making some changes in files content make sure that we get
      conflict during relocation.
      32c0b289
    • Pierre-Yves David's avatar
      divergence-resolution: [patch 1] fix a messed up test case · c0122b98
      Pierre-Yves David authored
      Because of logic change in divergence resolution which causes the order change
      in picking the resolution parent this test case was messed up.
      
      It was supposed to test that that it hits conflict while relocating the
      divergent cset but because of some change in previous patches, relocation went
      successful and it hits conflict while merging the two divergent csets.
      
      This patch, by making some changes in files content make sure that we get
      conflict during relocation.
      c0122b98
  26. Feb 17, 2021
  27. Feb 18, 2021
  28. Feb 01, 2021
  29. Jan 22, 2021
  30. Jan 28, 2021
  31. Feb 17, 2021
    • Kyle Lippincott's avatar
      doc: switch rst `=` section underlines to `-` · e117cf74
      Kyle Lippincott authored
      When using GENDOC_LOAD_CONFIGURED_EXTENSIONS=1, Mercurial's doc/gendoc.py can
      load extensions from outside of just the hgext directory, and pull in this doc.
      
      When added to the documentation, this should be nested inside of the following
      extension hierarchy:
      
      - Extensions
        - evolve
      
      The generated documentation has an established hierarchy of section headers, and
      the above uses `"` for top level, and `=` for each extension. Since gendoc just
      pastes it in verbatim, with `=` underlines, we get "Obsolescence Markers
      Discovery", "Effect Flag Experiment", and "Template keywords" as siblings to the
      evolve extension, instead of nested inside of it.
      
      This is not required for the string below it (that shows up with
      `hg help evolution`), as that is one level higher in the hierarchy (not nested
      inside of an "Extensions" section), so `=` is appropriate there.
      e117cf74
    • Kyle Lippincott's avatar
      doc: remove .strip() for a docstring · 96ed73c5
      Kyle Lippincott authored
      This shouldn't be necessary, and by stripping it (and removing the trailing
      newline) it causes issues with Mercurial's doc/gendoc.py's RST output, since
      there's no newline separating this string and the thing that comes after it.
      
      I believe that the `.strip()` has been in there since the beginning, but I have
      not found a reason for its existence. It's possible that this was required in
      older Mercurial versions, but is no longer required? Notably, the tests (which
      include an invocation of `hg help evolution`) still pass with this change.
      
      ### Alternatives considered
      
      - Making gendoc.py robust against this. This was rejected since there's no need
        for the .strip() as far as I can tell, and this is the only case I know of
        that would need such logic.
      96ed73c5
  32. Nov 25, 2020
    • Martin von Zweigbergk's avatar
      evolvecmd: don't update working copy when using in-memory merge · 84affb25
      Martin von Zweigbergk authored
      This patch removes the update of the working copy after each in-memory
      merge and only instead updates the working copy afterwards (if
      requested).
      
      There's still no significant speedup in the hg repo. It seems that the
      cost of updating the working copy is not large enough to make much
      difference, and the cost of reading and updating obsmarkers is
      relatively high in that repo. A significant part of the time (~35%) is
      spent in `repoview.computehidden()` because it is recalculated for
      every commit (seems like potential for improvement).
      
      I made similar changes in the mozilla-unified repo (which has a
      significantly larger working copy), by adding 10 commits each changing
      one line of a file. There, evolving 9 of those commits took 34s before
      this patch and 20s after. I measured similar speedups in an internal
      repo (9.0s -> 5.2s).
      84affb25
  33. Oct 15, 2020
    • Martin von Zweigbergk's avatar
      evolve: when relocating, optionally first try to do it using in-memory merge · c5dfbbe4
      Martin von Zweigbergk authored
      This patch adds a config option to let run evolve's relocation step
      using in-memory merge. It is disabled by default. When the option is
      on, the relocation is first attempted in memory. If that fails because
      of merge conflicts, it retries that commit in the working copy.
      
      There are a few reasons that I made it configurable. The most
      important one is that the precommit hook won't trigger when using
      in-memory merge. Another reason is that it lets us roll out the
      feature slowly to our users at Google.
      
      For now, we also update the working copy after creating the commit (in the
      successful case, when there are no merge conflicts). The next patch will make it
      so we don't do that update.
      
      Because of the unnecessary working-copy update, this patch doesn't
      provide any benefit on its own. Evolving 29 commits that each change
      one line in the hg slows down from ~4.5s to ~4.8s when the config
      option is on.
      
      I've added `#testcases inmemory ondisk` to select `.t` files. Almost
      all differences are because of the new "hit merge conflicts" message
      and retrying the merge. There's also one difference in
      `test-stabilize-order.t` caused by the different order of working copy
      updates (we now update the working copy at the end).
      c5dfbbe4
  34. Oct 01, 2020
  35. Oct 15, 2020
  36. Feb 09, 2021
  37. Feb 04, 2021
Loading