view tests/test-dirstate-race2.t @ 46667:93e9f448273c

rhg: Add support for automatic fallback to Python `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
author Simon Sapin <simon.sapin@octobus.net>
date Mon, 01 Mar 2021 20:36:06 +0100
parents 87a34c767384
children 93eb6c8035a9
line wrap: on
line source

Checking the size/permissions/file-type of files stored in the
dirstate after an update where the files are changed concurrently
outside of hg's control.

  $ hg init repo
  $ cd repo
  $ echo a > a
  $ hg commit -qAm _
  $ echo aa > a
  $ hg commit -m _

  $ hg debugdirstate --no-dates
  n 644          3 (set  |unset)               a (re)

  $ cat >> $TESTTMP/dirstaterace.py << EOF
  > from mercurial import (
  >     extensions,
  >     merge,
  > )
  > def extsetup(ui):
  >     extensions.wrapfunction(merge, 'applyupdates', wrap)
  > def wrap(orig, *args, **kwargs):
  >     res = orig(*args, **kwargs)
  >     with open("a", "w"):
  >         pass # just truncate the file
  >     return res
  > EOF

Do an update where file 'a' is changed between hg writing it to disk
and hg writing the dirstate. The dirstate is correct nonetheless, and
so hg status correctly shows a as clean.

  $ hg up -r 0 --config extensions.race=$TESTTMP/dirstaterace.py
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
  $ hg debugdirstate --no-dates
  n 644          2 (set  |unset)               a (re)
  $ echo a > a; hg status; hg diff