Skip to content
Snippets Groups Projects
  1. Aug 10, 2022
    • Arun Kulshreshtha's avatar
      dispatch: change cwd when loading local config · 3681a476
      Arun Kulshreshtha authored
      Previously, the `_getlocal` function would not correctly load the repo config
      when given a relative `rpath` and an alternate cwd via the `wd` parameter.
      
      Normally when `--cwd` is specified, hg changes to the given directory before
      attempting to load the local config (and therefore does not specify a `wd`).
      The only time the function is called with `wd` set is when hg is running as a
      command server (e.g., with chg), in which case each forked worker process will
      attempt to configure itself via `_getlocal` before responding to the client.
      When given a relative repo path, the worker fails to load the repo config,
      detects a config mismatch with the client, and enters a redirect/respawn loop.
      
      To fix this, we can simply change to the desired working directory during
      config loading. (Note that simply concatenating `wd` and `rpath` won't work
      in all cases. The repo path could be something more complicated than a simple
      relative path, such as a `union:` repo.)
      3681a476
  2. Aug 08, 2022
  3. Aug 12, 2022
  4. Aug 15, 2022
    • Arseniy Alekseyev's avatar
      revlog: make _partialmatch fail fast on almost-hex inputs · 5fe7e9ed
      Arseniy Alekseyev authored
      Before this change, resolving a revision like [0123456789^] on
      a large repo can take multiple seconds because:
      
      - hg does not realize this is a revset, so it tries various things,
      including _partialmatch(b"0123456789^")
      - after the rust lookup fails, it falls back to pure hg
      - pure hg takes all-but-last chars and converts them to binary,
      which *succeeds*, so it does the expensive part.
      5fe7e9ed
  5. Jul 11, 2022
  6. Jul 18, 2022
    • Matt Harbison's avatar
      setup: use the full executable manifest from `python.exe` · ece490b0
      Matt Harbison authored
      The manifest embedded by the build process (before the string here is added)
      already accounts for the `<requestedExecutionLevel level="asInvoker" ...>`
      setting.  (Note that the PyOxidizer build is missing this, so it will likely
      trigger the UAC escalation prompt on each run.)  However, using `mt.exe` to
      merge the fragment with what is already in the manifest seems to strip all
      whitespace, making it unreadable.
      
      Since Mercurial can be run via `python.exe`, it makes sense that we would have
      the same manifest settings (like the supported OS list), though I'm unaware of
      any functionality this enables.  It also has the nice effect of making the
      content readable from a resource editor.  The manifest comes from python 3.9.12.
      
      Note that this seems to strip the `<?xml ... ?>` declaration when viewed with
      ResourceHacker 5.1.7, but this was also the state of things with the previous
      commit, and `mt.exe "-inputresource:hg.exe;#1" -out:extracted` does contain the
      declaration and the BOM in both cases.  No idea why this differs from other
      executables.
      ece490b0
    • Matt Harbison's avatar
      setup: unconditionally enable the `long-paths-support` option on Windows · 747c4fc2
      Matt Harbison authored
      I don't see anything talking about why this was experimental in the first place,
      but maybe it was concern about the level of python2 support for it.  But now,
      both `python.exe` and the PyOxidizer build of `hg.exe` have a manifest that
      enables it, so leaving it off would mean some Mercurial installations could
      operate on a repo with long paths, and others couldn't.  Note that only the wide
      character functions (XxxW) will have the length restriction lifted.
      
      Sadly, distutils applies `/MANIFEST:EMBED` to the linker in a way that can't
      easily be turned off, so we can't use `/MANIFESTFILE` with `extra_preargs` on
      `link_executable`.  Fortunately, the compiler object provides a path to the
      `mt.exe` it found during initialization, because the previous incarnation seems
      to have assumed it is being run within an activated Visual Studio environment.
      That causes MSYS builds to fail, and probably would have broke the CI
      environment.
      747c4fc2
    • Matt Harbison's avatar
      setup: stop shadowing the builtin `dir` symbol · 5cf73de9
      Matt Harbison authored
      I hit this when debugging what's available on the compiler.
      5cf73de9
    • Kered13's avatar
      subrepo: avoid opening console window for non-native subrepos on Windows · b9fcf540
      Kered13 authored
      Prevent annoying command prompt windows popping up when using TortoiseHG with
      Git and SVN subrepos by passing creationflags=subprocess.CREATE_NO_WINDOW to
      subprocess.Popen.
      b9fcf540
  7. Jul 13, 2022
    • Matt Harbison's avatar
      ci: bump pytype to 2022.03.29 · 5baf873c
      Matt Harbison authored
      This is as far as we can go without running into issues with the vendored `attr`
      package.  I tried updating that to the latest, and not only did it not fix the
      issue, but test-util.py failed due to some poking at `attr` internals that
      apparently is no longer valid.
      
      The `libcst` package is now pinned to what I have locally because trying to
      install the latest (0.4.7) complains that it can't find the Rust compiler.  We
      should probably use a requirements file instead (and/or figure out why it can't
      find the Rust compiler), but I don't feel like dealing with another side quest.
      5baf873c
    • Matt Harbison's avatar
      typing: suppress a few attribute errors in url.py · 9f3edb30
      Matt Harbison authored
      These are newly detected by pytype 2022.03.21.  Not sure what is going on here-
      `realhostport` and `headers` are added outside of the constructor, so that makes
      sense.  But PyCharm also thinks the private methods don't exist, though when
      clicking through the class hierarchy, it shows in the py3.9 source code.
      9f3edb30
    • Matt Harbison's avatar
      typing: suppress a few pyi-errors with more recent pytype · 093e5c27
      Matt Harbison authored
      Not sure what's going on here, but these were flagged with pytype 2022.03.21.
      We can't update to something much more recent, because newer versions complain
      about various `attr` uses.
      093e5c27
    • Ondřej Pohořelský's avatar
      sslutil: another use proper attribute to select python 3.7+ · de2e158c
      Ondřej Pohořelský authored
      The previous attribute was python 3.6+, but guarded a python 3.7+ block
      
      Using the correct attribute avoids:
      +    File "/tmp/hgtests.bc0_uk2d/install/lib/python/mercurial/sslutil.py", line 577, in wrapserversocket
      +      sslcontext.minimum_version = ssl.TLSVersion.TLSv1_1
      +  AttributeError: module 'ssl' has no attribute 'TLSVersion'
      de2e158c
  8. Jul 12, 2022
    • Mathias De Mare's avatar
      sslutil: use proper attribute to select python 3.7+ · eec5e00e
      Mathias De Mare authored
      The previous attribute was python 3.6+, but guarded a python 3.7+ block.
      
      Using the correct attribute avoids:
        File "/usr/lib64/python3.6/site-packages/mercurial/sslutil.py", line 334, in wrapsocket
          sslcontext.minimum_version = ssl.TLSVersion.TLSv1_1
      AttributeError: module 'ssl' has no attribute 'TLSVersion'
      eec5e00e
  9. Jul 11, 2022
  10. Jul 10, 2022
    • Manuel Jacob's avatar
      procutil: make stream detection in make_line_buffered more correct and strict · 094a5fa3
      Manuel Jacob authored
      In make_line_buffered(), we don’t want to wrap the stream if we know that lines
      get flushed to the underlying raw stream already.
      
      Previously, the heuristic was too optimistic. It assumed that any stream which
      is not an instance of io.BufferedIOBase doesn’t need wrapping. However, there
      are buffered streams that aren’t instances of io.BufferedIOBase, like
      Mercurial’s own winstdout.
      
      The new logic is different in two ways:
      
      First, only for the check, if unwraps any combination of WriteAllWrapper and
      winstdout.
      
      Second, it skips wrapping the stream only if it is an instance of io.RawIOBase
      (or already wrapped). If it is an instance of io.BufferedIOBase, it gets
      wrapped. In any other case, the function raises an exception. This ensures
      that, if an unknown stream is passed or we add another wrapper in the future,
      we don’t wrap the stream if it’s already line buffered or not wrap the stream
      if it’s not line buffered. In fact, this was already helpful during development
      of this change. Without it, I possibly would have forgot that WriteAllWrapper
      needs to be ignored for the check, leading to unnecessary wrapping if stdout is
      unbuffered.
      
      The alternative would have been to always wrap unknown streams. However, I
      don’t think that anyone would benefit from being less strict. We can expect
      streams from the standard library to be subclassing either io.RawIOBase or
      io.BufferedIOBase, so running Mercurial in the standard way should not regress
      by this change. Py2exe might replace sys.stdout and sys.stderr, but that
      currently breaks Mercurial anyway and also these streams don’t claim to be
      interactive, so this function is not called for them.
  11. Jul 05, 2022
  12. May 25, 2022
  13. May 18, 2022
  14. Jun 12, 2022
  15. Jun 15, 2022
  16. Jun 16, 2022
Loading