undo-files: move the undo cleanup code in the transaction module Now that undo creation is gathered in the transaction module, let us move the code cleaning them up there too. This will be useful to better clean previous undo files up before creating new ones.

undo-files: drop the old undo rename logic It is no longer necessary I am not changing the transaction.__init__ signature since we are on stable right now.

undo-files: have the transaction directly tracks and manages journal rename This is much simpler this way.

undo-files: add a undoname closure to the _write_undo method We will also needs it when the transaction will take care of the other journal files, which is soon™.

undo-files: cleanup backup when cleaning undos Previously, the backups were left behind, by operation cleaning the undo's like strip, narrow and stream clone. The remaining elevant in the room is the transaction itself, who does not properly cleanup undo backup before copying the new ones.

undo-files: factor the vfs map in a repository property We define it in multiple locations and inconsistencies are appearing. So we now have a single definition point.

undo-files: add a utility function to read the backup-files definition We will need it in multiple places. so lets factor the logic around.

undo-files: use the cleanup function in streamclone Lets use the same code, so that we can fix things only once.

undo-files: also remove the undo.backupfiles The undo.backupfiles is dealt is directly managed by the transaction instead of going through the `localrepo.undofiles`. We start doing minimal management for it before using `cleanup_undo_files` on more situation. Proper handling of it is an intermediate goal of this series.

undo-files: use the cleanup function in narrow Lets use the same code, so that we can fix things only once.

undo-files: extract the cleanup code from strip in a function This logic is duplicated in multiple places and it missing some important parts. So lets start dealing with the duplication first.

run-tests: fix a crash when using the coverage options 35bf7f23b84c attempted to transition away from `distutils`, but the `packaging` code lacks `StrictVersion`. I have no idea when `packaging.version` became available, but I have it in python 3.6, so that should be good enough. For some reason, the import checker thinks this is a local import, and needs help to decide otherwise. Alternately we could ditch the version check entirely, because `coverage` is currently at 7.2.1, and the original check was added back in 2010.

rust: fix building on macOS (issue6801) The VFS change is copied over from Cargo, and likely to apply to other platforms as well. The dirstate change is essentially a replay of 440972d2175d, which was reverted in e98fd81bb151, part of !383, to silence some clippy warnings.

tests: fix timeout adjustement in delaypush.py Doing integer arithmetic with string is bound to fail.

revlog: add an exception hint when processing LFS flags without the extension It would be even better if this was either detected sooner, or the transaction completed (especially since the read/write processors aren't needed for the exchange). But this makes it easier for the user to resolve until that can be figured out.

tests: drop py36 conditionals in test-bad-extension.t Since this is a `>=` test, it's really conditionalizing py27 content, which isn't a thing anymore.

tests: drop py36 conditionals in test-hook.t Since this is a `>=` test, it's really conditionalizing py27 content, which isn't a thing anymore.

tests: drop py36 conditionals in test-http-bad-server.t Since this is a `>=` test, it's really conditionalizing py27 content, which isn't a thing anymore.

configitems: enable changegroup3 by default (unless using infinitepush) The LFS extension requires this, and if it isn't enabled on the client (or the LFS extension isn't loaded), a web client gets a 500 instead of a sensible error message. Now it gets a different (client) error, but maybe it can be handled more gracefully. c0f11347b107 indicates that treemanifest repos have this issue too. 29cfc474c5fd mentions gating this behind `experimental` so that the format could change, but that was 7 years ago and we now have an experimental `changegroup4` as well. We can keep this as a config for the next cycle in case someone runs into an unexpected problem, and then jettison it if the infinitepush bundle name changes are either acceptable as-is or can be created differently.

infinitepush: opt out of changegroup3 unless explicitly configured This is currently a no-op, as changegroup3 is disabled by default. But when it is enabled, it changes the hash names of the bundle files. As I don't use this extension, I have no idea if that's OK or not. So keep the current default behavior until we can get more info from actual users, while allowing them to opt-in for testing purposes.

statichttprepo: unbyteify several IOError messages Builtin errors generally want str messages.

statichttprepo: fix the vfs.join() method to match the base class definition Flagged by PyCharm. The superclass implementation raised NotImplementedError.

mail: unbyteify the SMTPException message This is a subclass of OSError, which wants str instead of bytes.

mail: add a missing argument to properly override starttls I didn't look into when this changed, but it was flagged by PyCharm.

crecord: switch a curses argument to bool to appease type checkers

grep: avoid reassigning byteskwargs to strkwargs PyCharm flagged each of these `get()` calls with bytes. We still pass the bytes form to the formatter to avoid changing the API, until all callers can be changed.

cat: drop unnecessary internal roundtrip of kwargs PyCharm seems to stick with the type at the initial assignment, so it flagged the `get()` with a bytes key since the method argument has str keys. It wasn't a bug, but then the bytes form is otherwise unused, and converted back to str.

relnotes: add 6.4 and empty next

Added signature for changeset 05de4896508e

Added tag 6.4rc0 for changeset 05de4896508e