lfconvert: use a `changing_parents` context to clear the dirstate Not sure if this is the right context, but it works and it is consistent with the other usages of `dirstate.clear`.

dirstate: mark the `copy` method as requiring a `changing_any` context This is used both when changing parents (e.g. merging with rename) and changing files (e.g. running `hg rename`).

dirstate: add a `require_changing_any` decorator We will need it for a couple of usecase (e.g `dirstate.copy`).

rebase: scope parent change into a changing_parents context If we are actually altering the working copy (i.e. we are not in memory), we should properly scope the working copy update.

dirstate: requires being in a `changing_parents` `context to set_parents` Enforcing proper operation scoping on all methods that mutate the dirstate will tighten correctness and reduce the risk of bugs. The context to use for this method is obvious, and all code was already compliant ☺

dirstate: invalidate on all exceptions Previously, we would miss SystemExit, KeyboardInterrupt etc. This "fix" on the bug tested in "test-largefiles-update.t" by preventing the precisely tested situation to happens at all. However this reveal a similar bug with a different timing. I have not been able to deal with that pre-existing bug so far. So I updated the test to point that out.

large-files: prepare a test for more changes The behavior around this test is about to change. We update the test to make it more robust and the changes clearer.

large-files: larger "changing_parents" context in mergeupdate override This since we are updating the lfdirstate early, it seems reasonable to include the full function in that scope.

large-files: use `hacky_extension_update_file` one more time This override is about merging and can be used in a `changing_parents` context. So lets use the method dedicated to hacky stuff when doing hacky stuff.

typing: disable `signature-mismatch` warnings on a few bytestr functions Recent versions of pytype complain about this, but it seems like expected behavior.

branching: merge with stable

rhg: fix a bug in path_encode This makes rhg able to access long paths at the root of the tree just fine.

rhg: demonstrate a bug in path_encode The bug means that long filenames at the root of the tree are encoded incorrectly by rhg, so rhg crashes when trying to access them.

rhg: nicer error message

typing: add type hints to argument checking functions in cmdutil These might be surprising, since they can take strings instead of bytes. The way `AnyStr` works is that it must be all bytes or all str for any given invocation. The wildcard here will be the `opts` that get passed in- if the type is unknown and defaults to `Any`, there's no enforcement that the dict key type matches the additional args. But a lot of uses should be using `**opts` from the command method, which has a str key. The uses of these methods in this module are now typed because their internals force a specific type, and it can't just be inferred from the caller.

tag: move the prohibition of tagging the `null` rev up to the `wdir()` check It makes sense to do these together, and avoid another revision lookup.

branching: merge with default the first part of the fix is there

tests: remove unnecessary --traceback argument

dirstate: remove the dedicated backup logic When alone, the dirstate can now take care of its commit/rollback pattern itself. When in a transaction, the transaction deal with commit/rollback pattern quite fine. Why did you have a dedicated backup logic?

localrepo: stop doing special dirstate backup at transaction open Since the dirstate writes are already managed by the transaction, we already do a backup of the dirstate when necessary (and even trigger one to keep `hg rollback` happy). We needs some special code to deal with the initial empty checkout, but it is not too complicated. Managing variable filename (as dirstate-v2 uses) at the "journalfile" level, is complex and fragile (which is consistent with the fact these files are not journal…). If we no longer do it, our life is significantly simpler. In some sense, we apply the xkcd-1134¹ solution to our savebackup/restorebackup problem. [1] https://xkcd.com/1134/ (the change to test-hardlink are expect as decreasing the number of duplicated backup drive the hardlink count down)

localrepo: "blindly" do a dirstate backup at the end of the transaction Having the file backup mechanism dealing with file backup as benefit. So lets move closer to that. The fact `hg rollback` even needs this is sad. I hope to have the time to implement one of the alternative soon.

test-hardlink: stop explicitly listing `undo.dirstate` The files is on its way out.

localrepo: enforce a clean dirstate when the transaction open This is important to simplify the backup process. This also seems like a quite reasonable expectation. See inline documentation for details.

dirstate: explicitly backup the datafile Since the transaction does not know about this file, we need to explicitly mark it for backup before touching it.

mq: write the dirstate before stripping I am not certain why it is dirty (probably the `repo.setparent` call a right before. However I know we need it flushed before the repository starts to be stripped.

dirstate: simplify the shelve hack to not go through the disk We already have the data in memory, so why not simply keep the data in memory? This avoid abusing the `savebackup/restorebackup` logic and will make our life easier.

dirstate: detect potential fishy transaction patterns while changing If we rely on the transaction more, we should be more careful about the transaction. Adding extra security seems reasonable.

dirstate: generalize the dirstate's invalidation on transaction abort The previous code was too specific, we should add the invalidation at next to the `addfilegenerator` in the `write` call.