##// END OF EJS Templates
mergestate: determine if active without looking for state files on disk...
mergestate: determine if active without looking for state files on disk I couldn't think of a reason that we need to check state files on disk to determine if a merge is active. I could imagine them being for there for detecting broken state files that would then be cleaned up by some later command, but we always delete the entire `.hg/merge/` tree, so that doesn't seem to be it. The checks were added in 4e932dc5c113 (resolve: abort when not applicable (BC), 2014-04-18). Perhaps there were needed for that and then made obsolete by 6062593d8b06 (resolve: don't abort resolve -l even when no merge is in progress, 2014-05-23). The reason I want to delete the checks is that I think `ms = mergestate.read(repo); ms.active() and ms.local` should be a valid pattern, but it crashes when the merge state file is an empty file if we consider mere presence of the file as "active". Differential Revision: https://phab.mercurial-scm.org/D8118

File last commit:

r44574:e1b8b4e4 default
r44878:5e3402a0 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