dirstate: reorder "state" checking conditional This is easier to read and will make this simpler to update in the next changeset. Differential Revision: https://phab.mercurial-scm.org/D10975

dirstate-entry: add a `need_delay` method This abstract the internal processing need for entry that would have an ambiguous mtime (If I understand things correctly). Differential Revision: https://phab.mercurial-scm.org/D10974

dirstate-entry: add a `tracked` property This abstract the individual `state` value and has a clear semantic. Differential Revision: https://phab.mercurial-scm.org/D10973

dirstate: drop `state` to `_addpath` All its value are inferred within the dirstatemap now. Differential Revision: https://phab.mercurial-scm.org/D10972

dirstate: infer the 'n' state from `from_p2` This flag is only used with 'n' so lets set the state based on that parameter in this case. Differential Revision: https://phab.mercurial-scm.org/D10971

dirstate: infer the 'n' state from `possibly_dirty` This flag is only used with 'n' so lets set the state based on that parameter in this case. Differential Revision: https://phab.mercurial-scm.org/D10970

dirstate: use a `merged` parameter to _addpath Differential Revision: https://phab.mercurial-scm.org/D10969

dirstate-entry: add a `added` property Lets use more semantic property instead of the `state` implementation details. Differential Revision: https://phab.mercurial-scm.org/D10968

dirstate: use a `added` parameter to _addpath My next target are the explicit `state` byte, so let start with abstracting their initial storage. Differential Revision: https://phab.mercurial-scm.org/D10967

dirstate: no longer pass the `oldstate` value to the dirstatemap The dirstatemap already have this information. Differential Revision: https://phab.mercurial-scm.org/D10966

dirstate: stop using `oldstate` in `dirstate._addpath` We don't need to pass the oldstate around, so lets use the new property instead. Differential Revision: https://phab.mercurial-scm.org/D10965

dirstate: drop the now unused magic constants for the dirstate module We no longer need them for the dirstate logic. We only need them in the dirstate map (and parsers) logic. This smell like progress. Differential Revision: https://phab.mercurial-scm.org/D10964

dirstate: move the handling of special case within the dirstatemap The dirstatemap is as well, if not better, suited to decided how to encode the various case. So we move the associated code in the dirstatemap `addfile` method. This means the dirstate no longer need to know about the various magic value used in the dirstate V1 format. The pain of the messy API start to be quite palpable in Rust, we should clean this up once the current large refactoring is dealt with. Differential Revision: https://phab.mercurial-scm.org/D10963

rust: bump rust-cpython version for 0.6.0 That function as a nice `is_none` method on `PyObject` that we will put to use. Differential Revision: https://phab.mercurial-scm.org/D10962

rust-dirstate: make the MTIME_UNSET public We will use it in the cpython layer soon. Differential Revision: https://phab.mercurial-scm.org/D10961

rust-dirstatemap: expand the wrapping code a bit This is easier to read. Differential Revision: https://phab.mercurial-scm.org/D10960

dirstate-entry: restrict `from_p2` property to tracked file The other case is now handled in `from_p2_removed`, and should ideally be moved to a lower level. So we can drop the `state == 'n'` narrowing and move it in the property itself. Differential Revision: https://phab.mercurial-scm.org/D10959

dirstate-entry: `merged_removed` and `from_p2_removed` properties Lets start to define and use more semantic property. These two might be a bit too low level and could be shaved off later, however this seems an improvement for now. Differential Revision: https://phab.mercurial-scm.org/D10958

dirstate-entry: add a `removed` property Lets start to define and use more semantic property. Differential Revision: https://phab.mercurial-scm.org/D10957

dirstate-entry: add a `from_p2` property Lets start to define and use more semantic property. Differential Revision: https://phab.mercurial-scm.org/D10956

dirstate-entry: add a `merged` property Lets start to define and use more semantic property. Differential Revision: https://phab.mercurial-scm.org/D10955

dirstate-entry: add a `state` property (and use it) This replace the [0] access. Ultimately is we should probably get ride of this in its current form. However this is a good transitional solution to move away for tuple indexing for now. Differential Revision: https://phab.mercurial-scm.org/D10954

dirstate: move most of the `remove` logic with dirstatemap `removefile` This code deal with special logic to preserving "merged" and "from_p2" information when removing a file. These are implementation details that are more suitable for the dirstatemap layer. Since the dirstatemap layer alreaday have most of the information necessary to do so, the move is easy. This move helps us to encapsulate more implementation details within the dirstatemap and its entry. Easing the use of a different storage for dirstate v2. Differential Revision: https://phab.mercurial-scm.org/D10953

dirstate: add a `in_merge` property This factor the "p2 is not null" check and is fairly simpler to read. Differential Revision: https://phab.mercurial-scm.org/D10952

dirstate-entry: introduce dedicated accessors for v1 serialization In the spirit of changing the content and storage of the dirstate entry, we add new method that the code doing v1 serialisation can use. Adding such method to the C object is quite trivial. Differential Revision: https://phab.mercurial-scm.org/D10951

dirstate-entry: goes through the `dirstatetuple` constructor in all cases We need to make sure we build an object. Differential Revision: https://phab.mercurial-scm.org/D10950

dirstate-entry: turn dirstate tuple into a real object (like in C) With dirstate V2, the stored information and actual format will change. This mean we need to start an a better abstraction for a dirstate entry that a tuple directly accessed. By chance, the C code is already doing this and pretend to be a tuple. So it should be fairly easy. We start with turning the tuple into an object, we will slowly migrate the dirstate code to no longer use the tuple directly in later changesets. Differential Revision: https://phab.mercurial-scm.org/D10949

Added signature for changeset 411dc27fd9fd

Added tag 5.8.1 for changeset 411dc27fd9fd

corruption: backout changeset 49fd21f32695 (issue6528) inverting the parent is masking copy information leading to bad content being fetched and bad status result. Since 49fd21f32695, exchange can actively swap these parent corrupting existing changesets and triggering the corruption. Data corruption are considered critical so backing this out and doing and unscheduled release seems in order. Differential Revision: https://phab.mercurial-scm.org/D10995

corruption: add a test for issue6528 The initial reproduction script was provided by Charles Chamberlain from Jane Street. Differential Revision: https://phab.mercurial-scm.org/D10996

stream: double check that self.vfs is *not* in the vfsmap The stream clone logic allows for writing any content to any file under various vfs. This is *not* suitable for *vfs*, since writing in `.hg/` directly allow to modify the configuration and is a great and simple gateway for remote code execution. Differential Revision: https://phab.mercurial-scm.org/D10905

dirstate: split dirstatemap in its own file The dirstate file is large enough and the dirstatemap is quite insulated logic already. Differential Revision: https://phab.mercurial-scm.org/D10934

run-tests: stop writing a `python3` symlink pointing to python2 Having `python3` actually pointing to `python2` is bad. So we stop doing so. In addition we need to re-introduce a `python` executable since some of the script really need to be able to say "current python" in their shbang. For example, `hghave` is one of such script. The faulty changes where introduced by c102b704edb5. Differential Revision: https://phab.mercurial-scm.org/D10943

check-code: stop forbidding return code result There is no explication of what is the intend of that check and what is the alternative. I suspect this comes from the transition to the "unified test" format circa 2010. With the non zero return explicitly listed in the output explicit $? checking became Redundant. However there is valid use case for checking $? so I am dropping this check. Differential Revision: https://phab.mercurial-scm.org/D10994

run-tests: avoid an early return To fix the "python3 pointing to python2" we will also need to create a "python" pointer. So we will need to create multiple pointer. So we need to stop using early return. We replace the early return with a loop and a continue, since the next changeset will introduce that loop anyway. Differential Revision: https://phab.mercurial-scm.org/D10942

run-tests: clarify pyexename assignement That assignement is wrong, we clarify that it is wrong before starting to fix it. This will make the fix clearer. Differential Revision: https://phab.mercurial-scm.org/D10941

run-tests: factor appdata out This is a gratuitous readability change. Differential Revision: https://phab.mercurial-scm.org/D10940

run-tests: unroll a non-so-one-liner This is shorter and clearer. Differential Revision: https://phab.mercurial-scm.org/D10939

run-tests: unroll a non-so-one-liner This is shorter and clearer. Differential Revision: https://phab.mercurial-scm.org/D10938

testing: fix _timeout_factor With `--debug`, `run-tests.py` set the timeout to 0... that breaks the logic in `mercurial.testing`. Differential Revision: https://phab.mercurial-scm.org/D10937

exchange: use "served" repo filter to guess what the server will publish Previously, the second push in the added test would say "push would publish 2 changesets" because _checkpublish() was considering secret changesets to be "pushable" when push command had a --rev argument. Without --rev argument to push command, we already filter the repo properly. Differential Revision: https://phab.mercurial-scm.org/D10948

rust: Document the DirstateMapMethods trait Differential Revision: https://phab.mercurial-scm.org/D10919

dirstate: document the dirstatetuple content We are about to modify this, so let us document the existing code. Differential Revision: https://phab.mercurial-scm.org/D10935

dirstate: explicitely deal with the `added` case in `_addpath` This special case is now directly handled, this clarify the possible value for the other options. Differential Revision: https://phab.mercurial-scm.org/D10933

dirstate: add an explicit `possibly_dirty` parameter to `_addpath` This lets says what we mean instead of using magic value. The lower level can then decide how to express that. Differential Revision: https://phab.mercurial-scm.org/D10932

dirstate: add an explicit `from_p2` parameter to `_addpath` This lets says what we mean instead of using magic value. The lower level can then decide how to express that. Differential Revision: https://phab.mercurial-scm.org/D10931

dirstate: add default value to _addpath We want to remove the magic value usage from the higher level, so lets stop passing them explicitely when possible. Differential Revision: https://phab.mercurial-scm.org/D10930