revlog: drop an unused variable assignment It's assigned again 2 lines later.

lfs: improve an exception message for blob corruption detected on transfer The message about the server crash originated in 0ee0a3f6a990 (after support for serving blobs was added), but was copied from the Facebook repo that forked prior to server side support. Therefore, this message only displayed in their client, so it was safe to assume the server crashed. But that was never the case for vanilla Mercurial, as I saw this in a server log. Also, display the blob reference so that it's easier to figure out where the problem was when a bunch of blobs are transferred at once.

relnotes: add 6.3

Added signature for changeset a3356ab610fc

Added tag 6.3rc0 for changeset a3356ab610fc

branching: merge stable into default

branching: merge default into stable This marks the feature freeze for the 6.3 release

lfs: fix interpolation of int and %s in an exception case Seen in the wild in a server log when MS antivirus was quarantining a file on the client side.

tests: catch "Can't assign requested address" in test-https.t (issue6726)

tests: add another variation of EADDRNOTAVAIL message (e.g. from NetBSD)

shelve: re-wrap now that the line fits

shelve: avoid setting overloading tmpwctx

configitems: change the `verify.skipflags` default value to avoid a py3 crash The revlog and LFS modules use various `&` and `&=` operations with this value, which no longer treats `None` as 0. Since nothing cares if it was actually set in the config or not, just default to 0 for simplicity.

dirstate-v2: skip evaluation of hgignore regex on cached directories By making the computation of [has_ignored_ancestor] lazy we're eliding its computation in the common case when none of its descendants have changed on disk. On a ~400k files repo, with a cached status, we saw a ~64% reduction in CPU time, resulting in a speedup of ~10-15% (on ZFS), and a speedup of ~38% of XFS (XFS has faster stat operations for some reason).

releasenotes: use re.MULTILINE mode when checking admonitions Release note admonitions must start at the beginning of a line within the changeset description: .. admonitions:: The checkadmonitions function search for and validates admonitions. Unfortunately, since the ctx.description is multi-line, the regex search always fails unless the admonition is on the first line. This changeset adds re.MULTILINE to the re.compile to make the re opbject multi-line.

windows: gracefully handle when the username cannot be determined This assumes implementation details, but I don't see any other way than to check the environment variables ourselves (which would miss out on any future enhancements that Python may make). This was originally reported as https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5835.

rhg: parallellize computation of [unsure_is_modified] [unsure_is_modified] is called for every file for which we can't determine its status based on its size and mtime alone. In particular, this happens if the mtime of the file changes without its contents changing. Parallellizing this improves performance significantly when we have many of these files. Here's an example run (on a repo with ~400k files after dropping FS caches) ``` before: real 0m53.901s user 0m27.806s sys 0m31.325s after: real 0m32.017s user 0m34.277s sys 1m26.250s ``` Another example run (a different FS): ``` before: real 3m28.479s user 0m31.800s sys 0m25.324s after: real 0m29.751s user 0m41.814s sys 1m15.387s ```

rhg: enable in case ui.statuscopies=True rhg already has code to support ui.statuscopies, but it's disabled, for seemingly no good reason.

rhg: share some code

rhg: support tweakdefaults

rhg: centralize PlainInfo

rhg: central treatment of PLAIN and PLAINEXCEPT

revset: handle wdir() in `sort(..., -topo)` The last apparent usage of `repo.changelog.parentrevs` in revsets is in `children()`, but since the sets being operated on never include wdir(), it's never called with `wdirrev` and the wdir() arg on the command line is effectively ignored instead of aborting there. I'm not sure how to fix that. Before (on a clone of hg): $ python3.8 hg perf::revset --config extensions.perf=contrib/perf.py 'sort(all(), -topo)' ! wall 0.123663 comb 0.130000 user 0.130000 sys 0.000000 (best of 76) After: $ python3.8 hg perf::revset --config extensions.perf=contrib/perf.py 'sort(all(), -topo)' ! wall 0.123838 comb 0.130000 user 0.130000 sys 0.000000 (best of 75)

revset: handle wdir() in `roots()` This is already handled in `heads()`, and both are needed to determine if a set is contiguous. I'm guessing the `0 <= p` check was to try to filter out the null revision, but it looks like that comes through in the corner case of a new repo with no commits. But that was already the case, as shown by the tests. Before (on a clone of hg): $ python3.8 hg perf::revset --config extensions.perf=contrib/perf.py 'roots(all())' ! wall 0.059301 comb 0.040000 user 0.040000 sys 0.000000 (best of 100) After: $ python3.8 hg perf::revset --config extensions.perf=contrib/perf.py 'roots(all())' ! wall 0.059387 comb 0.060000 user 0.060000 sys 0.000000 (best of 100)

pull_logger: add basic log file rotation based on size

contrib: add pull_logger extension This extension logs the pull parameters, i.e. the remote and common heads, when pulling from the local repository. The collected data should give an idea of the state of a pair of repositories and allow replaying past synchronisations between them. This is particularly useful for working on data exchange, bundling and caching-related optimisations.

shelve: do not add the dirstate backup to the transaction Otherwise the transaction will properly clean up its mess on abort… deleting the backup in the process. This break with dirstate-v2 that has more file than just the dirstate. The dirstate itself is full of various exception and is "fine" when using dirstate-v1.

branching: merge stable into default

Added signature for changeset dbdee8ac3e3f

Added tag 6.2.3 for changeset dbdee8ac3e3f