##// END OF EJS Templates
rust-nodemap: accounting for dead blocks...
rust-nodemap: accounting for dead blocks By the very append-only nature of the `NodeTree`, inserting new blocks has the effect of making some of the older ones useless as they become unreachable. Therefore some automatic housekeeping will need to be provided. This is standard procedure in the word of databases, under names such as "repack" or "vacuum". The new `masked_readonly_blocks()` will provide callers with useful information to decide if the nodetree is ripe for repacking, but all the `NodeTree` can provide is how many blocks have been masked in the currently mutable part. Analysing the readonly part would be way too long to do it for each transaction and defeat the whole purpose of nodemap persistence. Serializing callers (from the Python layer) will get this figure before each extraction and maintain an aggregate counter of unreachable blocks separately. Note: at this point, the most efficient repacking is just to restart afresh with a full rescan. Differential Revision: https://phab.mercurial-scm.org/D8097

File last commit:

r44574:e1b8b4e4 default
r44873:6329ce04 default
Show More
README.rst
52 lines | 1.7 KiB | text/x-rst | RstLexer
Gregory Szorc
rust: implementation of `hg`...
r35587 ===================
Mercurial Rust Code
===================
This directory contains various Rust code for the Mercurial project.
Valentin Gatien-Baron
rust: add a README...
r44574 Rust is not required to use (or build) Mercurial, but using it
improves performance in some areas.
Gregory Szorc
rust: implementation of `hg`...
r35587
Valentin Gatien-Baron
rust: add a README...
r44574 There are currently three independent rust projects:
- chg. An implementation of chg, in rust instead of C.
- hgcli. A experiment for starting hg in rust rather than in python,
by linking with the python runtime. Probably meant to be replaced by
PyOxidizer at some point.
- hg-core (and hg-cpython/hg-directffi): implementation of some
functionality of mercurial in rust, e.g. ancestry computations in
revision graphs or pull discovery. The top-level ``Cargo.toml`` file
defines a workspace containing these crates.
Using hg-core
=============
Gregory Szorc
rust: implementation of `hg`...
r35587
Valentin Gatien-Baron
rust: add a README...
r44574 Local use (you need to clean previous build artifacts if you have
built without rust previously)::
Gregory Szorc
rust: implementation of `hg`...
r35587
Valentin Gatien-Baron
rust: add a README...
r44574 $ HGWITHRUSTEXT=cpython make local # to use ./hg
$ HGWITHRUSTEXT=cpython make tests # to run all tests
$ (cd tests; HGWITHRUSTEXT=cpython ./run-tests.py) # only the .t
$ ./hg debuginstall | grep rust # to validate rust is in use
checking module policy (rust+c-allow)
Gregory Szorc
rust: implementation of `hg`...
r35587
Valentin Gatien-Baron
rust: add a README...
r44574 Setting ``HGWITHRUSTEXT`` to other values like ``true`` is deprecated
and enables only a fraction of the rust code.
Gregory Szorc
rust: implementation of `hg`...
r35587
Valentin Gatien-Baron
rust: add a README...
r44574 Developing hg-core
==================
Simply run::
Gregory Szorc
rust: implementation of `hg`...
r35587
$ cargo build --release
Valentin Gatien-Baron
rust: add a README...
r44574
It is possible to build without ``--release``, but it is not
recommended if performance is of any interest: there can be an order
of magnitude of degradation when removing ``--release``.
For faster builds, you may want to skip code generation::
$ cargo check
You can run only the rust-specific tests (as opposed to tests of
mercurial as a whole) with::
$ cargo test --all