Fri, 22 Nov 2019 20:27:09 -0800 debugcommands: add Python implementation to debuginstall
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 22 Nov 2019 20:27:09 -0800] rev 44145
debugcommands: add Python implementation to debuginstall This seems like a useful detail to print. Differential Revision: https://phab.mercurial-scm.org/D7979
Fri, 22 Nov 2019 20:12:10 -0800 run-tests: remove --py3-warnings
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 22 Nov 2019 20:12:10 -0800] rev 44144
run-tests: remove --py3-warnings This Python 2 only mode was to help Python 2 alert when doing things not supported on Python 3. Now that we have test coverage with Python 3, I don't think we need it. Differential Revision: https://phab.mercurial-scm.org/D7978
Wed, 22 Jan 2020 16:37:05 +0100 rust-node: binary Node ID and conversion utilities
Georges Racinet <georges.racinet@octobus.net> [Wed, 22 Jan 2020 16:37:05 +0100] rev 44143
rust-node: binary Node ID and conversion utilities The choice of type makes sure that a `Node` has the exact wanted size. We'll use a different type for prefixes. Added dependency: hexadecimal conversion relies on the `hex` crate. The fact that sooner or later Mercurial is going to need to change its hash sizes has been taken strongly in consideration: - the hash length is a constant, but that is not directly exposed to callers. Changing the value of that constant is the only thing to do to change the hash length (even in unit tests) - the code could be adapted to support several sizes of hashes, if that turned out to be useful. To that effect, only the size of a given `Node` is exposed in the public API. - callers not involved in initial computation, I/O and FFI are able to operate without a priori assumptions on the hash size. The traits `FromHex` and `ToHex` have not been directly implemented, so that the doc-comments explaining these restrictions would stay really visible in `cargo doc` Differential Revision: https://phab.mercurial-scm.org/D7788
Wed, 22 Jan 2020 16:23:29 +0100 rust-nodemap: building blocks for nodetree structures
Georges Racinet <georges.racinet@octobus.net> [Wed, 22 Jan 2020 16:23:29 +0100] rev 44142
rust-nodemap: building blocks for nodetree structures This is similar to `nodetreenode` in `revlog.c`. We give it a higher level feeling for ease of handling in Rust context and provide tools for tests and debugging. The encoding choice is dictated by our ultimate goal in this series, that is to make an append-only persistent version of `nodetree`: the 0th Block must be adressed from other Blocks. Differential Revision: https://phab.mercurial-scm.org/D7787
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -4 +4 +10 +30 +100 +300 +1000 +3000 tip