##// END OF EJS Templates
bundlerepo: fix mismatches with repository and revlog classes...
bundlerepo: fix mismatches with repository and revlog classes Both pytype and PyCharm complained that `write()` and `_write()` in the bundlephasecache class aren't proper overrides- indeed they seem to be missing an argument that the base class has. PyCharm and pytype also complained that the `revlog.revlog` class doesn't have a `_chunk()` method. That looks like it was moved from revlog to `_InnerRevlog` back in e8ad6d8de8b8, and wasn't caught because this module wasn't type checked. However, I couldn't figure out a syntax with `revlog.revlog._inner._chunk(self, rev)`, as it complained about passing too many args. `bundlerevlog._rawtext()` uses this `super(...)` style to call the super class, so hopefully that works, even with the wonky dynamic subclassing. The revlog class needed the `_InnerRevlog` field typed because it isn't set in the constructor. Finally, the vfs type hints look broken. This initially failed with: File "/mnt/c/Users/Matt/hg/mercurial/bundlerepo.py", line 65, in __init__: Function readonlyvfs.__init__ was called with the wrong arguments [wrong-arg-types] Expected: (self, vfs: mercurial.vfs.vfs) Actually passed: (self, vfs: Callable) Called from (traceback): line 232, in dirlog line 214, in __init__ I don't see a raw Callable, but I tried changing some of the vfs args to be typed as `vfsmod.abstractvfs`, but that class doesn't have `options`, so it failed elsewhere. `readonlyvfs` isn't a subclass of `vfs` (it's a subclass of `abstractvfs`), so I'm not sure how to handle that. It would be a shame to have to make a union of vfs subclasses (but not all of them have `options` either).
Matt Harbison -
r52764:cfd30df0 default
Show More
Name Size Modified Last Commit Author
/ rust / rhg
src
Cargo.toml Loading ...
README.md Loading ...

rhg

The rhg executable implements a subset of the functionnality of hg
using only Rust, to avoid the startup cost of a Python interpreter.
This subset is initially small but grows over time as rhg is improved.
When fallback to the Python implementation is configured (see below),
rhg aims to be a drop-in replacement for hg that should behave the same,
except that some commands run faster.

Building

To compile rhg, either run cargo build --release from this rust/rhg/
directory, or run make build-rhg from the repository root.
The executable can then be found at rust/target/release/rhg.

Mercurial configuration

rhg reads Mercurial configuration from the usual sources:
the user’s ~/.hgrc, a repository’s .hg/hgrc, command line --config, etc.
It has some specific configuration in the [rhg] section.

See hg help config.rhg for details.

Installation and configuration example

For example, to install rhg as hg for the current user with fallback to
the system-wide install of Mercurial, and allow it to run even though the
rebase and absorb extensions are enabled, on a Unix-like platform:

  • Build rhg (see above)
  • Make sure the ~/.local/bin exists and is in $PATH
  • From the repository root, make a symbolic link with
    ln -s rust/target/release/rhg ~/.local/bin/hg
  • Configure ~/.hgrc with:
[rhg]
on-unsupported = fallback
fallback-executable = /usr/bin/hg
allowed-extensions = rebase, absorb
  • Check that the output of running
    hg notarealsubcommand
    starts with hg: unknown command, which indicates fallback.

  • Check that the output of running
    hg notarealsubcommand --config rhg.on-unsupported=abort
    starts with unsupported feature:.