Skip to content
Snippets Groups Projects
  1. Jun 19, 2024
    • Raphaël Gomès's avatar
      revlog: add the glue to use the Rust `InnerRevlog` from Python · 7346f93be7a4
      Raphaël Gomès authored
      The performance of this has been looked at for quite some time, and some
      workflows are actually quite a bit faster than with the Python + C code.
      
      However, we are still (up to 20%) slower in some crucial places like cloning
      certain repos, log, cat, which makes this an incomplete rewrite. This is
      mostly due to the high amount of overhead in Python <-> Rust FFI, especially
      around the VFS code. A future patch series will rewrite the VFS code in
      pure Rust, which should hopefully get us up to par with current perfomance,
      if not better in all important cases.
      
      This is a "save state" of sorts, as this is a ton of code, and I don't want
      to pile up even more things in a single review.
      
      Continuing to try to match the current performance will take an extremely
      long time, if it's not impossible, without the aforementioned VFS work.
      7346f93be7a4
    • Raphaël Gomès's avatar
      changelog: also set the general delta config flag in the data config · 13815c9decd4
      Raphaël Gomès authored
      This duplication is dubious, but it's a decision to be made at a later date,
      this is the fix.
      13815c9decd4
  2. Jul 29, 2024
  3. Oct 10, 2024
    • Raphaël Gomès's avatar
      rust-revlog: add a Rust-only `InnerRevlog` · e01e84e5e426
      Raphaël Gomès authored
      This mirrors the Python `InnerRevlog` and will be used in a future patch
      to replace said Python implementation. This allows us to start doing more
      things in pure Rust, in particular reading and writing operations.
      
      A lot of changes have to be introduced all at once, it wouldn't be very
      useful to separate this patch IMO since all of them are either interlocked
      or only useful with the rest.
      e01e84e5e426
    • Raphaël Gomès's avatar
      rust-index: fix the computation of data start · 44823c5011fe
      Raphaël Gomès authored
      This was falling into place instead of being correct, we clean up the logic
      by differenciating the on-disk offset and the actual start of the data
      more cleanly.
      44823c5011fe
    • Raphaël Gomès's avatar
      rust-index: return an error on a bad index header · f2eab4967bfc
      Raphaël Gomès authored
      This is more idiomatic and allows us to better handle the problem later.
      f2eab4967bfc
  4. Oct 17, 2024
  5. Sep 25, 2024
  6. Oct 29, 2024
  7. Oct 27, 2024
  8. Oct 28, 2024
  9. Oct 25, 2024
    • Pierre-Yves David's avatar
      evolution: stop wrongly flagging unrelated part of a split as divergent · e68fe567a780
      Pierre-Yves David authored
      Before this change, divergence introduced by successors of a split would "spill"
      to other unrelated successors of the split that were not ambiguous.
      
      This small changes fixes it.
      
      Thanks goes to Manuel Jacobs for the discussion leading to this realization that
      a new simple and correct definition could be found.
      e68fe567a780
  10. Oct 27, 2024
    • Matt Harbison's avatar
      tests: skip doctests that use `time.tzset()` on Windows · cf8d029a480b
      Matt Harbison authored
      There's no way to conditionally skip the tests for a function (see the inline
      feature request).  That leaves us with the choice to either put the whole
      `mercurial.utils.dateutil` module in the skip list of this script (but then this
      script prints out the module as unexpectedly not tested, and misses a bunch of
      tests that can be run), blacklist the test entirely (but that makes it harder to
      work with on Windows), or use this hack to look for the statement that is
      broken, and skip the test currently attached to one function.
      
      (It appears that an example in the list of examples corresponds to a single
      `>>>` block, and the `test` itself corresponds to a single function.  So prescan
      the examples, and skip all of them when the statement is found in any, since the
      setup of setting the timezone has an effect on subsequent examples.)
      cf8d029a480b
  11. Oct 07, 2024
    • Arseniy Alekseyev's avatar
      tests: hopefully fix `test-doctest.py` on Windows and more · 479899e53816
      Arseniy Alekseyev authored
      1. Shell syntax understood by `shell=True` depends on the platform.
      Instead, pass `shell=False` and call `sh` explicitly to interpret
      the command correctly.
      
      2. Stop setting `HGRCPATH=/dev/null`, so the setting
      `experimental.evolution=createmarkers` is set correctly.
      The reason I set HGRCPATH to /dev/null previously is because of
      misunderstanding where I thought the Python script had no HGRC to edit.
      As it turns out, there is in fact a valid temporary HGRC pointed to by
      HGRCPATH in this context so we don't seem to need this. /shrug
      479899e53816
  12. Oct 26, 2024
    • Matt Harbison's avatar
      hghave: make the description for "clang-format" ascii · f1312d0803a8
      Matt Harbison authored
      test-fix-clang-format.t suddenly started failing on Windows by wiping the whole
      file content, and replacing with an error:
      
            $TESTTMP.sh: $TESTTMP.sh: cannot execute binary file
      
      Odd, because I don't have `clang-format` installed, so the test should be
      skipped.  The problem started with 73cf8b56c2f5, and I noticed that running
      `hghave` manually resulted in a `SyntaxError` (so I can't see how this isn't
      broken everywhere, but maybe it's because I'm using py3.9 on Windows):
      
          $ py hghave --list
          Traceback (most recent call last):
            File "hghave", line 8, in <module>
              import hghave
            File "c:\Users\Matt\hg\tests\hghave.py", line 627
          SyntaxError: Non-ASCII character '\xe2' in file c:\Users\Matt\hg\tests\hghave.py on line 627, but no encoding declared;
              see http://python.org/dev/peps/pep-0263/ for details
      f1312d0803a8
    • Pierre-Yves David's avatar
      branching: merge stable into default · e08c878b5571
      Pierre-Yves David authored
      Hopefully this will bring the last changes necessary to make the 3.13 tests
      green (on Linux).
      e08c878b5571
    • Matt Harbison's avatar
      2dce4c01cec1
    • Matt Harbison's avatar
      typing: suppress bogus pytype errors in `mercurial/wireprotov1peer.py` · 8b791764fc52
      Matt Harbison authored
      Fixes:
      
          File "/mnt/c/Users/Matt/hg/mercurial/wireprotov1peer.py", line 100, in result:
              No attribute '_peerexecutor' on unsentfuture [attribute-error]
          File "/mnt/c/Users/Matt/hg/mercurial/wireprotov1peer.py", line 278, in close:
              No attribute 'shutdown' on None [attribute-error]
          Called from (traceback):
            line 123, in __exit__
          File "/mnt/c/Users/Matt/hg/mercurial/wireprotov1peer.py", line 278, in close:
              No attribute 'shutdown' on None [attribute-error]
            In Optional[concurrent.futures.thread.ThreadPoolExecutor]
      
      We drop the zope decorator on `peerexecutor`, because otherwise it triggers this
      error:
      
          File "/tmp/mercurial-ci/mercurial/wireprotov1peer.py", line 111, in <module>:
              Invalid type annotation  [invalid-annotation]
            Must be constant
      
      Not sure why, because the decorated classes usually get typed as `Any`, which
      would also be fine here.
      8b791764fc52
    • Matt Harbison's avatar
      ff13068e9b1c
    • Matt Harbison's avatar
      typing: suppress bogus pytype errors in `mercurial/wireprotoframing.py` · 0c260e7158e0
      Matt Harbison authored
      This fixes:
      
          File "/mnt/c/Users/Matt/hg/mercurial/wireprotoframing.py", line 480, in createalternatelocationresponseframe:
              unsupported operand type(s) for item assignment: bytes [unsupported-operands]
            No attribute '__setitem__' on bytes
          File "/mnt/c/Users/Matt/hg/mercurial/wireprotoframing.py", line 510, in createcommanderrorresponse:
              unsupported operand type(s) for item assignment: bytes [unsupported-operands]
            No attribute '__setitem__' on bytes
          File "/mnt/c/Users/Matt/hg/mercurial/wireprotoframing.py", line 776, in __init__:
              Can't find module 'mercurial.zstd'. [import-error]
          File "/mnt/c/Users/Matt/hg/mercurial/wireprotoframing.py", line 804, in __init__:
              Can't find module 'mercurial.zstd'. [import-error]
          File "/mnt/c/Users/Matt/hg/mercurial/wireprotoframing.py", line 834, in populatestreamencoders:
              Can't find module 'mercurial.zstd'. [import-error]
      
      Using `TypedDict` is tempting here to fix the first two, but requires str keys.
      The code doing the importing doesn't call the code at the other three locations
      if the `mercurial.zstd` module fails to import in a place that handles the
      ImportError.
      0c260e7158e0
  13. Oct 25, 2024
    • Matt Harbison's avatar
      wireprototypes: make `baseprotocolhandler` methods abstract · fd200f5bcaea
      Matt Harbison authored
      The documentation says it's an abstract base class, so let's enforce it.  The
      `typing.Protocol` class is already an ABC, but it only prevents instantiation if
      there are abstract attrs that are missing.  For example, from `hg debugshell`:
      
          >>> from mercurial import wireprototypes
          >>> x = wireprototypes.baseprotocolhandler()
          Traceback (most recent call last):
            File "<console>", line 1, in <module>
          TypeError: Can't instantiate abstract class baseprotocolhandler with abstract method name
          >>> class fake(wireprototypes.baseprotocolhandler):
          ...     pass
          ...
          >>> x = fake()
          Traceback (most recent call last):
            File "<console>", line 1, in <module>
          TypeError: Can't instantiate abstract class fake with abstract method name
      
      That's great, but it doesn't protect against calling non-abstract methods at
      runtime, rather it depends on the protocol type hint being added to method
      signatures or class attrs, and then running a type checker to notice when an
      instance is assigned that doesn't conform to the protocol.  We don't widely use
      type hints yet, and do have a lot of class hierarchy in the repository area,
      which could lead to surprises like this:
      
          >>> class fake(wireprototypes.baseprotocolhandler):
          ...     @property
          ...     def name(self) -> bytes:
          ...         return b'name'
          ...
          >>> z = fake()
          >>> z.client()
          >>> print(z.client())
          None
      
      Oops.  That was supposed to return `bytes`.  So not only is a bad/unexpected
      value returned, but it's one that violates the type hints (since the base
      client() method will be annotated to return bytes).  With this change, we get:
      
          >>> from mercurial import wireprototypes
          >>> class fake(wireprototypes.baseprotocolhandler):
          ...     @property
          ...     def name(self) -> bytes:
          ...         return b'name'
          ...
          >>> x = fake()
          Traceback (most recent call last):
            File "<console>", line 1, in <module>
          TypeError: Can't instantiate abstract class fake with abstract methods
              addcapabilities, checkperm, client, getargs, getpayload, getprotocaps, mayberedirectstdio
      
      So this looks like a reasonable safety harness to me, and lets us catch problems
      by running the standard tests while the type hints are being added, and pytype
      is improved.  We should probably do this for all Protocol class methods that
      don't supply a method implementation.
      fd200f5bcaea
    • Matt Harbison's avatar
      wireprototypes: convert `baseprotocolhandler.name` to an abstract property · e7812caacc3c
      Matt Harbison authored
      PyCharm was flagging the subclasses where this was declared as a `@property`
      with
      
          Type of 'name' is incompatible with 'baseprotocolhandler'
      
      But pytype didn't complain.  This seems more correct, however.  Since `Protocol`
      is already an `abc.ABCMeta` class, we don't need to mess with the class
      hierarchy.
      e7812caacc3c
    • Matt Harbison's avatar
    • Matt Harbison's avatar
      wireprototypes: convert `baseprotocolhandler` to a Protocol class · 47981c4bfeee
      Matt Harbison authored
      The methodology for doing this is now known, and this is limited to two
      implementing classes, so just make the changes.
      47981c4bfeee
  14. Oct 26, 2024
Loading