Skip to content
Snippets Groups Projects
  1. Jan 20, 2021
  2. Jan 28, 2021
  3. Feb 13, 2021
  4. Feb 25, 2021
  5. Mar 12, 2021
  6. Mar 10, 2021
  7. Feb 25, 2021
  8. Mar 04, 2021
  9. Mar 02, 2021
  10. Mar 01, 2021
    • Simon Sapin's avatar
      rhg: Add support for automatic fallback to Python · 93e9f448273c
      Simon Sapin authored
      `rhg` is a command-line application that can do a small subset of what
      `hg` can. It is written entirely in Rust, which avoids the cost of starting
      a Python interpreter and importing many Python modules.
      In a script that runs many `hg` commands, this cost can add up.
      
      However making users decide when to use `rhg` instead of `hg` is
      not practical as we want the subset of supported functionality
      to grow over time.
      
      Instead we introduce "fallback" behavior where, when `rhg` encounters
      something (a sub-command, a repository format, …) that is not implemented
      in Rust-only, it does nothing but silently start a subprocess of
      Python-based `hg` running the same command.
      That way `rhg` becomes a drop-in replacement for `hg` that sometimes
      goes faster. Whether Python is used should be an implementation detail
      not apparent to users (other than through speed).
      
      A new `fallback` value is added to the previously introduced
      `rhg.on-unsupported` configuration key. When in this mode, the new
      `rhg.fallback-executable` config is determine what command to use
      to run a Python-based `hg`.
      
      The previous `rhg.on-unsupported = abort-silent` configuration was designed
      to let a wrapper script call `rhg` and then fall back to `hg` based on the
      exit code. This is still available, but having fallback behavior built-in
      in rhg might be easier for users instead of leaving that script "as an
      exercise for the reader".
      
      Using a subprocess like this is not idea, especially when `rhg` is to be
      installed in `$PATH` as `hg`, since the other `hg.py` executable needs
      to still be available… somewhere. Eventually this could be replaced
      by using PyOxidizer to a have a single executable that embeds a Python
      interpreter, but only starts it when needed.
      
      Differential Revision: https://phab.mercurial-scm.org/D10093
      93e9f448273c
    • Simon Sapin's avatar
      rhg: Add a `rhg.on-unsupported` configuration key · 33f2d56acc73
      Simon Sapin authored
      For now the two values are:
      
      * `abort-silent`: silently exit with code 252, the previous default behavior
      * `abort`: print an error message about what feature
        is not supported, then exit with code 252. Now the default.
      
      Differential Revision: https://phab.mercurial-scm.org/D10091
      33f2d56acc73
    • Simon Sapin's avatar
      7284b524b441
  11. Mar 02, 2021
  12. Mar 09, 2021
  13. Feb 15, 2021
  14. Jan 11, 2021
    • Simon Sapin's avatar
      copies-rust: add a macro-based unit-testing framework · fa21633af201
      Simon Sapin authored
      `compare_values`, `merge_copies_dict`, and `CombineChangesetCopies`
      are APIs whose signatures involve non-trivial types.
      Calling them directly in unit tests would involve a lot of verbose
      setup code that obscures the meaningful parts of a given test case.
      
      This adds a macro-based test-harness with pseudo-syntax to tersely
      create arguments and expected return values in the correct types.
      
      For now there is only one (not particularly meaningful) test case
      per tested function, just to exercize the macros.
      
      Differential Revision: https://phab.mercurial-scm.org/D10071
      fa21633af201
  15. Jan 06, 2021
  16. Mar 08, 2021
  17. Mar 01, 2021
  18. Feb 15, 2021
  19. Dec 24, 2020
    • Matt Harbison's avatar
      tests: demonstrate a case where a corrupt tag cache causes an abort · 9ea6b75b4a95
      Matt Harbison authored
      I happened to hit this trying to cover other cases around valid vs missing
      entries.  I have no idea if this is something that could occur more naturally
      (similar to how a missing file node in `hgtagsfnodes1` can occur after a strip).
      There is a test just above this added in f5a7cf0adb12 mentioning it "overwrites
      the junk", though that tests truncation instead of actual garbage.
      
      But since this is just a cache, it probably shouldn't abort with a cryptic
      message like this.  The two options I see both have downsides- either rebuild
      the cache (and potentially take a long time), or hint to the user to run a debug
      command.
      
      Differential Revision: https://phab.mercurial-scm.org/D9812
      9ea6b75b4a95
  20. Feb 16, 2021
  21. Feb 10, 2021
  22. Mar 04, 2021
    • Martin von Zweigbergk's avatar
      copies: filter out copies grafted from another branch · 2803f94b7431
      Martin von Zweigbergk authored
      Consider this simple history:
      
      ```
      @  3 modify y
      |
      o  2 copy x to y, modify x
      |
      | o  1 copy x to y, modify x
      |/
      o  0 add x
      
      ```
      
      If we now rebase commit 3 onto 1, Mercurial will look for copies
      between commit 2 and commit 1. It does that by going backwards from 2
      to 0 and then forwards from 0 to 1. It will find that x was copied to
      y, since that was what happened on the path between them (namely in
      commit 1). That leads Mercurial to do a 3-way merge between y@3 and
      y@1 with x@2 as base. We want to use y@2 as base instead. That's also
      what happened until commit 1d6d1a15a963. This patch fixes the regression
      by adding another filtering step when chaining copies via a
      diffbase. The new filtering step removes copies that were the same
      between the two branches (same source and destination, but not
      necessarily the same contents).
      
      Differential Revision: https://phab.mercurial-scm.org/D10120
      2803f94b7431
  23. Mar 05, 2021
  24. Mar 07, 2021
  25. Mar 06, 2021
Loading