dirstate: Don’t drop unrelated data in DirstateMap::set_entry For example, copy source are handled separately. Removing it goes through the `copy_map_remove` method (exposed to Python as `.copymap.pop()`) Differential Revision: https://phab.mercurial-scm.org/D11488

dirstate: Skip no-op conversion in Rust DirstateMap::set_v1 Now that the `DirstateItem` python class is implemented in Rust containing a `DirstateEntry` value, use that value directly instead of reconstructing it from v1 data. Also rename from `set_v1` since dirstate-v1 data is not used anymore. Differential Revision: https://phab.mercurial-scm.org/D11487

dirstate: Use the Rust implementation of DirstateItem when Rust is enabled … instead of the C implementation, with C/Rust conversions at the FFI boundary Differential Revision: https://phab.mercurial-scm.org/D11486

rust: Add Python bindings for DirstateEntry as rustext.dirstate.DirstateItem Differential Revision: https://phab.mercurial-scm.org/D11485

rust: Align DirstateEntry internals with Python/C DirstateItem This propagate to this Rust struct the similar change that was made recently to the Python classe and C struct. Namely, instead of storing a four-valued `state` field we now store seven (bit-packed) booleans that give lower-level information. Additionally, the marker values -1 and -2 for mtime and size should not be used internally anymore. They are replaced by some combinations of booleans For now, all uses of of `DirstateEntry` still use the compatibility APIs with `state` and marker values. Later the Rust API for DirstateMap will be increasingly updated to the new style. Also change the expected result of the test_non_normal_other_parent_entries unit test. Only a `DirstateEntry` with `size == -2 && mtime != -1` is affected, but this case never occurs outside of unit tests. `size == -2` was the marker value for "from other parent" entries, where no meaningful mtime is stored. Differential Revision: https://phab.mercurial-scm.org/D11484

branching: merge stable into default

manifestlog: also monitor `00manifest.n` when applicable This let the locarepo's file cache detect outdated nodemap docket and reload the manifestlog after `localrepo.invalidate` when applicable. The same problem than issue6554 could affect the Manifest too. Differential Revision: https://phab.mercurial-scm.org/D11483

changelog: also monitor `00changelog.n` when applicable (issue6554) This let the locarepo's file cache detect outdated nodemap docket and reload the changelog after `localrepo.invalidate` when applicable. Differential Revision: https://phab.mercurial-scm.org/D11482

persistent-nodemap: introduce a test to highlight possible race Weakness in the current file caching of the changelog means that a writer can end up using an outdated docket. This might result in "committed" persistent-nodemap data from a previous writer to be overwritten by a later writer. This break the strong "append only" assumption of the persistent nodemap and can result in confused reader. The race windows are quite narrow. See the test documentation for details. The issues is fixed in the next changeset. Differential Revision: https://phab.mercurial-scm.org/D11481

test: enable share-safe in test-persistent-nodemap We will use some share in this test and I would rather have them safe. Differential Revision: https://phab.mercurial-scm.org/D11480