##// END OF EJS Templates
dirstate-v2: Add storage space for nanoseconds precision in file mtimes...
dirstate-v2: Add storage space for nanoseconds precision in file mtimes For now the sub-second component is always set to zero for tracked files and symlinks. (The mtime of directories for the `readdir`-skipping optimization is a different code path and already uses the full precision available.) This extra storage uses the space previously freed by replacing the 32-bit `mode` field by two bits in the existing `flags` field, so the overall size of nodes is unchanged. (This space had been left as padding for this purpose.) Also move things around in the node layout and documentation to have less duplication. Now that they have the same representation, directory mtime and file mtime are kept in the same field. (Only either one can exist for a given node.) Differential Revision: https://phab.mercurial-scm.org/D11655

File last commit:

r47575:d4ba4d51 default
r49033:308d9c24 default
Show More
README.md
50 lines | 2.0 KiB | text/x-minidsrc | MarkdownLexer
Gregory Szorc
hgcli: customize for Mercurial...
r45129 # Oxidized Mercurial
This project provides a Rust implementation of the Mercurial (`hg`)
version control tool.
Under the hood, the project uses
[PyOxidizer](https://github.com/indygreg/PyOxidizer) to embed a Python
interpreter in a binary built with Rust. At run-time, the Rust `fn main()`
is called and Rust code handles initial process startup. An in-process
Python interpreter is started (if needed) to provide additional
functionality.
# Building
This project currently requires an unreleased version of PyOxidizer
(0.7.0-pre). For best results, build the exact PyOxidizer commit
as defined in the `pyoxidizer.bzl` file:
$ git clone https://github.com/indygreg/PyOxidizer.git
$ cd PyOxidizer
$ git checkout <Git commit from pyoxidizer.bzl>
$ cargo build --release
Then build this Rust project using the built `pyoxidizer` executable::
$ /path/to/pyoxidizer/target/release/pyoxidizer build
If all goes according to plan, there should be an assembled application
under `build/<arch>/debug/app/` with an `hg` executable:
$ build/x86_64-unknown-linux-gnu/debug/app/hg version
Mercurial Distributed SCM (version 5.3.1+433-f99cd77d53dc+20200331)
(see https://mercurial-scm.org for more information)
Raphaël Gomès
contributor: change mentions of mpm to olivia...
r47575 Copyright (C) 2005-2020 Olivia Mackall and others
Gregory Szorc
hgcli: customize for Mercurial...
r45129 This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
# Running Tests
To run tests with a built `hg` executable, you can use the `--with-hg`
argument to `run-tests.py`. But there's a wrinkle: many tests run custom
Python scripts that need to `import` modules provided by Mercurial. Since
these modules are embedded in the produced `hg` executable, a regular
Python interpreter can't access them! To work around this, set `PYTHONPATH`
to the Mercurial source directory. e.g.:
$ cd /path/to/hg/src/tests
$ PYTHONPATH=`pwd`/.. python3.7 run-tests.py \
--with-hg `pwd`/../rust/hgcli/build/x86_64-unknown-linux-gnu/debug/app/hg