Thu, 06 Dec 2018 16:34:22 +0100 rust-cpython: build via HGWITHRUSTEXT=cpython
Georges Racinet <gracinet@anybox.fr> [Thu, 06 Dec 2018 16:34:22 +0100] rev 40967
rust-cpython: build via HGWITHRUSTEXT=cpython The existing behaviour, building the direct ffi bindings if HGIWTHRUSTEXT is just set is unchanged, but if HGWITHRUSTEXT is cpython, then the cpython bindings (aka mercurial/rustext.so) are built. Differential Revision: https://phab.mercurial-scm.org/D5436
Thu, 06 Dec 2018 16:23:20 +0100 rust: better treatment of cargo/rustc errors
Georges Racinet <gracinet@anybox.fr> [Thu, 06 Dec 2018 16:23:20 +0100] rev 40966
rust: better treatment of cargo/rustc errors Differential Revision: https://phab.mercurial-scm.org/D5435
Mon, 03 Dec 2018 06:52:17 +0100 rust-cpython: start cpython crate bindings
Georges Racinet <gracinet@anybox.fr> [Mon, 03 Dec 2018 06:52:17 +0100] rev 40965
rust-cpython: start cpython crate bindings This changeset introduces the hg-cpython crate, that compiles as a shared library holding a whole Python package (mercurial.rustext), with only the empty 'ancestor' submodule for now. Such bindings will be easier and safer to develop and maintain that those of `hg-direct-ffi`. They don't involve C code, only unsafe Rust that's mostly isolated within the cpython crate. The long-term goal would be to import the provided modules, such as rustext.ancestor with mercurial.policy.importmod, same as we already do with cext modules. Differential Revision: https://phab.mercurial-scm.org/D5434
Mon, 03 Dec 2018 06:54:19 +0100 rust-cpython: exclude hgcli from workspace
Georges Racinet <gracinet@anybox.fr> [Mon, 03 Dec 2018 06:54:19 +0100] rev 40964
rust-cpython: exclude hgcli from workspace hgcli uses a specific rust-cpython commit by indygreg, of which a PR has been derived which is not merged nor released yet. But we can't use several versions of the sys-python2.7 crate in a single workspace: it makes for a build error. Since hgcli does not at the time being need anything from hg-core, whereas the upcoming hg-cpython will. So for now we're moving hgcli aside, hoping we could base all of them on the same version of rust-cpython again in the future. Differential Revision: https://phab.mercurial-scm.org/D5433
Fri, 14 Dec 2018 17:25:41 +0100 sparse-revlog: protect C code against delta chain including nullrev
Boris Feld <boris.feld@octobus.net> [Fri, 14 Dec 2018 17:25:41 +0100] rev 40963
sparse-revlog: protect C code against delta chain including nullrev For unclear reasons, some repositories include nullrev (-1). Re-computing delta for such repo remove nullrev from all chain, so some older versions have been creating them. This currently raise an IndexError with the new C code doing chain slicing as it expect all item to be positive. Both python and C code for reading delta chain preserve nullrev, and the Python code for chain slicing handle the case fine. So we take the safe route and make the new C code works fine in that case.
Fri, 14 Dec 2018 17:24:44 +0100 sparse-revlog: handle nullrev in index_get_length
Boris Feld <boris.feld@octobus.net> [Fri, 14 Dec 2018 17:24:44 +0100] rev 40962
sparse-revlog: handle nullrev in index_get_length The more generic index_get method handle nullrev fine, we apply the same logic here.
Fri, 14 Dec 2018 17:23:41 +0100 sparse-revlog: handle nullrev in index_get_start
Boris Feld <boris.feld@octobus.net> [Fri, 14 Dec 2018 17:23:41 +0100] rev 40961
sparse-revlog: handle nullrev in index_get_start The more generic index_get method handle nullrev fine, we apply the same logic here.
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -7 +7 +10 +30 +100 +300 +1000 +3000 +10000 tip