Skip to content
Snippets Groups Projects
  1. Feb 19, 2025
    • Mitchell Kember's avatar
      rust-revset: support resolving wdir() · bb30c89f1ffb
      Mitchell Kember authored
      This makes revset::resolve_single return RevisionOrWdir. Previously, it returned
      RevlogError::WDirUnsupported (leading to abort, not fallback) for 2147483647 and
      ffffffffffffffffffffffffffffffffffffffff. It did not recognize 'wdir()' itself,
      so that would lead to Python fallback. Now, it treats all 3 cases the same: it
      returns RevisionOrWdir::wdir() and lets the caller decide what to do.
      
      I changed rhg cat, files, and annotate to return HgError::unsupported in this
      case, since wdir is valid. I made `rhg status --change wdir()` behave the same
      as `rhg status`, conforming to the test in test-status.t.
      bb30c89f1ffb
    • Mitchell Kember's avatar
      rust-revlog: add RevisionOrWdir · 1a99e0c2d6d5
      Mitchell Kember authored
      This type represents either a checked Revision or the wdir() pseudo-revision
      (revision 0x7fffffff, node ffffffffffffffffffffffffffffffffffffffff).
      
      You construct it with revision.into() or Revision::wdir(), and destructure it
      with rev.exclude_wdir() which returns Option<Revision>.
      
      I considered something like `enum RevisionOrWdir { Wdir, Revision(Revision) }`,
      but decided on `struct RevisionOrWdir(BaseRevision)` for a few reasons:
      
      - It's more ergonomic for the ways it actually gets used, in my opinion.
      - It also avoids the possibility of an invalid value Revision(0x7fffffff).
      - It remains 4 bytes rather than 8.
      - It maintains the ordering: wdir is greater than all other revisions.
      
      I'm planning to use this for 'rhg annotate -r wdir()'.
      1a99e0c2d6d5
  2. Feb 14, 2025
    • Mitchell Kember's avatar
      rust-config: add username parsing · 879029f03324
      Mitchell Kember authored
      This adds Config::username which returns HGUSER, ui.username, or EMAIL in that
      order, similar to ui.username() in Python.
      
      I considered following the pattern of EDITOR, VISUAL, PAGER, etc. and using
      add_for_environment_variable, but it's not possible to get the same precendence
      as in Python that way (in particular HGUSER coming after the repo .hg/hgrc), at
      least not without significant changes.
      
      This will be used for 'rhg annotate -r wdir() -u' to annotate the username on
      lines that were changed in the working directory.
      879029f03324
  3. Mar 06, 2025
  4. Mar 05, 2025
  5. Mar 01, 2025
  6. Feb 28, 2025
  7. Feb 25, 2025
  8. Feb 26, 2025
    • Raphaël Gomès's avatar
      rhg-files: use the correct long-form flag for selecting a revision · 65f6f1fe43ef
      Raphaël Gomès authored
      This went unnoticed forever, I guess most users pass in `-r`.
      65f6f1fe43ef
    • Matt Harbison's avatar
      packaging: fetch gettext dependencies from m-s.o instead of sourceforge · 0570351db4e7
      Matt Harbison authored
      The SourceForge packages were working as recently as late last week, and then
      yesterday I suddenly got a failure that the size of the download changed from
      what was expected.  Let's not trust SourceForge for critical things (though
      the MinGW package manager likely uses that too; I'm not sure how to fix that).
      
      We probably don't need this at all, now that `install-windows-dependencies.ps1`
      installs `gettext` 0.22.5 since da74e81ef9af.  But I don't feel like tinkering
      with the packaging code at this point, and running that PowerShell script in CI
      is probably pretty heavy handed.
      0570351db4e7
  9. Feb 24, 2025
    • Mitchell Kember's avatar
      rust-annotate: do not impl Sync for Lines · 3ac28aa1430e
      Mitchell Kember authored
      I failed to notice before that bdiff_diff mutates its inputs by storing
      bookkeeping information in the `n` and `e` fields. This means &Lines can't be
      shared across threads, so Lines cannot be Sync. Fortunately nothing was using
      this. The parallel file reading and line splitting only relies on Send.
      
      The reason I didn't notice this to begin with was that Lines contains a
      *mut ffi::bdiffline, which is accessible from &Lines, so I never wrote or
      thought about &mut Lines. This pattern (using a mutable pointer stored in an
      immutable struct) would be expressed with RefCell if this was pure safe Rust.
      3ac28aa1430e
  10. Feb 25, 2025
  11. Feb 22, 2025
    • Matt Harbison's avatar
      setup: drop the inaccessible `py2exehacked` code around distutils · e2c239dae5a2
      Matt Harbison authored
      The comment heavily implies, and experimenting confirms, that there's no
      `sys.real_prefix` in a venv on Python3.  I have no idea how the problems
      described would manifest, but nobody has complained for the several years of
      py3 releases build from a venv.  The experimenting was done with 6.9.2 and the
      TortoiseHg build script.
      e2c239dae5a2
  12. Feb 24, 2025
    • Matt Harbison's avatar
      docs: update the IRC channel reference in the Windows readme · 80ec613fea43
      Matt Harbison authored
      I noticed this when trying the Inno installer.
      80ec613fea43
    • Matt Harbison's avatar
      packaging: adapt `__version__.py` parsing for `setuptools_scm` output · d333e14477f1
      Matt Harbison authored
      The file is now generated by `setuptools_scm`, which stores values as strings
      with strong quotes.  This avoids the following failure at the end of the Inno
      installer build:
      
              <snip>
              creating installer
              Traceback (most recent call last):
                File "c:\Users\Matt\projects\mercurial\mercurial-devel\contrib\packaging\packaging.py", line 70, in <module>
                  run()
                File "c:\Users\Matt\projects\mercurial\mercurial-devel\contrib\packaging\packaging.py", line 62, in run
                  cli.main()
                File "c:\Users\Matt\projects\mercurial\mercurial-devel\contrib\packaging\hgpackaging\cli.py", line 154, in main
                  args.func(**kwargs)
                File "c:\Users\Matt\projects\mercurial\mercurial-devel\contrib\packaging\hgpackaging\cli.py", line 35, in build_inno
                  inno.build_with_pyoxidizer(
                File "c:\Users\Matt\projects\mercurial\mercurial-devel\contrib\packaging\hgpackaging\inno.py", line 55, in build_with_pyoxidizer
                  build_installer(
                File "c:\Users\Matt\projects\mercurial\mercurial-devel\contrib\packaging\hgpackaging\inno.py", line 146, in build_installer
                  version = read_version_py(source_dir)
                File "c:\Users\Matt\projects\mercurial\mercurial-devel\contrib\packaging\hgpackaging\util.py", line 188, in read_version_py
                  raise Exception('could not parse %s' % p)
              Exception: could not parse c:\Users\Matt\projects\mercurial\mercurial-devel\mercurial\__version__.py
      
      Note that non-tagged builds end up with complex version strings, and include
      characters that WiX rejects.  That's probably fine- we don't do nightly or other
      non-tagged builds for installers.
      
      Also note that while the Inno installer is capable of using this version string
      as part of the installer, the WiX installer is not for some reason.  That
      installer needs to be built with `--version VERSION` to inject the version into
      the installer metadata and the filename.
      d333e14477f1
    • Matt Harbison's avatar
      contrib: add modern `setuptools` and `setuptools_scm` to the packaging venv · 0e2be2abd963
      Matt Harbison authored
      With `py -3.9 contrib/packaging/packaging.py wix --pyoxidizer-target x86_64-pc-windows-msvc`,
      there is an immediate failure after building the venv (3.9.13 has `setuptools`
      58.1.0):
      
          ModuleNotFoundError: No module named 'setuptools.command.build'
      
      With that fixed, the same command then fails immediately with this error:
      
          Couldn't import setuptools_scm (direct call of setup.py?)
      
      Unfortunately, referencing `setuptools` in the requirements file needs
      `--allow-unsafe` to avoid a warning about not pinning `setuptools`.  However,
      the same warning happens if `setuptools` is pinned to a specific revision, so I
      have no idea what it is complaining about.  It's a separate venv that is only
      used for packaging, so we can fix it if it becomes a problem in the future.
      
      Interestingly, the Inno installer build doesn't fail immediately, and I can see
      it installing `setuptools` and `setuptools_scm` in the wall of text it emits.
      Eventually it does fail with the same errors without this change.
      0e2be2abd963
  13. Feb 22, 2025
  14. Feb 21, 2025
  15. Feb 20, 2025
    • Pierre-Yves David's avatar
      cleanup: drop the LIBDIR related code · 33e06272ff1a
      Pierre-Yves David authored
      This code is no longer used as the python packaging echo system evolved.
      
      This code was introduced in 10da5a1f25dd, with two feature in mind:
      
      - Mercurial may be installed into a non-standard location without
        having to set PYTHONPATH.
      - Multiple installations can use Mercurial from different locations.
      
      As a side effect it also provided performance improvement at a time where the
      `sys.path` could be greatly inflated from setuptools `.pth` files. And it also
      protected from incompatible directory within the `$PTYHONPATH` variable. Both of
      these benefit has faded overtime as `.pth` are less common and `$PYTHONPATH` is
      less used (as both where creating issue to more than just Mercurial).
      
      The initial motivation (easily install Mercurial anywhere), can now be handled
      by a new generation of tool like pipx or uv, so it is less of a concern.
      
      Regardless of all the above, the current code is no longer used. The evolution
      of python packaging means that installation always go through first building a
      location agnostic "wheel" that cannot update LIBDIR to a proper location.
      Upstream packaging (debian, redhat, etc…) does not seems to adjust this variable
      themself. So it is safer to drop this dead code that pretend we could be doing
      something with it.
      33e06272ff1a
    • Pierre-Yves David's avatar
      cleanup: remove the `contrib/hgperf` script · b624da86830e
      Pierre-Yves David authored
      This script seems a copy `./hg` with a few adjustment. However it does not seems
      to have been used in age given that is still use old API and package name that
      has not been around for a long while.
      
      So let's just delete it.
      b624da86830e
    • Matt Harbison's avatar
      test-fix-path: avoid a test hang on Windows · 3fb2fbad4b13
      Matt Harbison authored
      Windows can't typically invoke `*.py` directly as a command, and will instead
      show a prompt asking what program should be used to open the file.  We can't
      directly invoke the interpreter as is usually done in this case, because the
      whole point is to run something not in `PATH`.  The easiest thing to do is
      invoke a *.bat file that runs the interpreter.  We can get away with this
      because the current implementation is to effectively run `cmd.exe /c %command%`,
      which doesn't need the file extension specified.
      3fb2fbad4b13
  16. Feb 19, 2025
    • Pierre-Yves David's avatar
      stream-clone: adjust default value for worker and memory · e75ed9ae5fb9
      Pierre-Yves David authored
      Increasing the memory usage does not seems to yield much speed up, so we can
      restrict it more aggressively. However, unlimited memory usage can overwhelm a
      system and result in massive slowdown if the process start swapping. So it is
      still possible to configure it, but it is not longer used in any default
      profile.
      
      Having too many workers can slow things a bit, but not too much. So we can try
      to use higher default to yield benefit on large system.
      e75ed9ae5fb9
Loading