view tests/test-sparse-requirement.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

  $ hg init repo
  $ cd repo

  $ touch a.html b.html c.py d.py

  $ cat > frontend.sparse << EOF
  > [include]
  > *.html
  > EOF

  $ hg -q commit -A -m initial

  $ echo 1 > a.html
  $ echo 1 > c.py
  $ hg commit -m 'commit 1'

Enable sparse profile

  $ cat .hg/requires
  dotencode
  fncache
  generaldelta
  revlogv1
  sparserevlog
  store
  testonly-simplestore (reposimplestore !)

  $ hg debugsparse --config extensions.sparse= --enable-profile frontend.sparse
  $ ls -A
  .hg
  a.html
  b.html

Requirement for sparse added when sparse is enabled

  $ cat .hg/requires
  dotencode
  exp-sparse
  fncache
  generaldelta
  revlogv1
  sparserevlog
  store
  testonly-simplestore (reposimplestore !)

Client without sparse enabled reacts properly

  $ hg files
  abort: repository is using sparse feature but sparse is not enabled; enable the "sparse" extensions to access
  [255]

Requirement for sparse is removed when sparse is disabled

  $ hg debugsparse --reset --config extensions.sparse=

  $ cat .hg/requires
  dotencode
  fncache
  generaldelta
  revlogv1
  sparserevlog
  store
  testonly-simplestore (reposimplestore !)

And client without sparse can access

  $ hg files
  a.html
  b.html
  c.py
  d.py
  frontend.sparse