context: use `dirstate.set_tracked` for `revert` This is the new shiny API. Differential Revision: https://phab.mercurial-scm.org/D11016

context: use `dirstate.set_tracked` in context.copy This is the new shiny API. Differential Revision: https://phab.mercurial-scm.org/D11015

context: use `dirstate.set_tracked` in `context.add` This is the new shiny API. Differential Revision: https://phab.mercurial-scm.org/D11014

dirstate: add a `set_tracked` method for "hg add"-like usage This is a step further toward clarifying the semantic of various dirstate call. Having a dedicated function comes with a couple of benefits: 1) we can move duplicated logic about how to handle the previous state within the dirstate. Since we are sure this is always called in the same situation, we can implement that logic once in the dirstate. 2) having a dedicated method for this case unlock also having a dedicated method for the other case and recording more information at that time. All this leading having more code within the dirstate and higher level API that are less error prone. Differential Revision: https://phab.mercurial-scm.org/D11013

dirstate: add a function to update tracking status while "moving" parents The `scmutil.dirstateparent` is moving the dirstate parent without touching the working copy. It is used by history-rewriting operations like amending of folding. The function was directly doing the "low level" computation and dirstate change. All that logic belong to the dirstate and should be moved there. For this purpose we introduce a new function that does just that and use it. Differential Revision: https://phab.mercurial-scm.org/D11012

dirstate: introduce an internal `_drop` method We want to split current user of `dirstate.drop` between `hg rm`-like cases and update of the dirstate coming from update/merge. To do this we will introduce new API. The first step is to introduces an internal function that these new API migh use (or not use) to distinct between the migrated users and the others. Differential Revision: https://phab.mercurial-scm.org/D11023

dirstate: introduce an internal `_remove` method We want to split current user of `dirstate.remove` between `hg rm`-like cases and update of the dirstate coming from update/merge. To do this we will introduce new API. The first step is to introduces an internal function that these new API migh use (or not use) to distinct between the migrated users and the others. Differential Revision: https://phab.mercurial-scm.org/D11011

dirstate: introduce an internal `_add` method We want to split current user of `dirstate.add` between `hg add`-like cases and update of the dirstate coming from update/merge. To do this we will introduce new API. The first step is to introduces an internal function that these new API migh use (or not use) to distinct between the migrated users and the others. Differential Revision: https://phab.mercurial-scm.org/D11010

run-tests: rely on an actual executable in PATH instead of alias for `hg` The alias approach is poorly inherited by other process that the test might spawn. To solve this we use the same approach as for `python`/`python3` we write an executable file explicitly. Doing this fixes `which hg` invocation that now returns the same location as `hg`. Using chg server side has some minor effect on some stdout/stderr ordering when using `chg` as the server too. Differential Revision: https://phab.mercurial-scm.org/D11053

tests: blacklist a handful of test with `rhg` or `chg` The use of `alias` to enforce `chg` and `rhg` means we are actually using a mix of `rhg`/`chg` and `hg` when calling `hg` in the test. Fixing this breaks various tests. This would be a large detour to fix that. I am disabling them for now with an appropriate comment. We would hopefully get back to them by the 5.8 release. Differential Revision: https://phab.mercurial-scm.org/D11052