Added tag 6.4 for changeset f14864fffdca

relnotes: do 6.4

hooks: invalidate the repo after the hooks Since the hooks may have changed the repository content it seems safer to invalidate it. The invalidation is "soft", the data are kept around and few work will be needed to restore them if nothing actually changed.

dirstate: try refreshing the changelog when parent are unknown See inline comment for details.

localrepo: add a `currentlock` method It mirrors he `currentwlock` function.

dirstate: add a test to highlight another changelog / dirstate race

rust: fix thread cap (for real this time) Both e2f8ed37201c and c52435820bbd failed to put a *default* ceiling on the number of threads used by Rayon to prevent a contention issue. Calling `rayon::available_parallelism()` creates the global threadpool, which made our whole dance useless last time.

tests: accept a test output change in [tests/test-serve.t] This fixes a breakage introduced in adecb1ab4a0d. It was not caught by the CI probably because allows binding to port 13.

py3: fix for Python 3.12 emitting SyntaxWarning on invalid escape sequences Missed in 805d4a462abb: $ python3.12 mercurial/store.py mercurial/store.py:406: SyntaxWarning: invalid escape sequence '\.' EXCLUDED = re.compile(b'.*undo\.[^/]+\.(nd?|i)$')

url: don't ignore timeout for https connections For http, we use the stdlib's HTTPConnection.connect which passes the timeout down to socket.create_connection; for https, we override the connect method but weren't handling the timeout, so connections could hang for hours even with http.timeout set to low values.

debugdeltachain: stop summing the same chain over and over Before this patch, delta chain size was computed from scratch for each chain, disregarding the fact very likely already computed the same of length-1 prefix for another revisions. We not cache delta chain size and shortcut the computation when we see them. Just for my mercurial-devel clone, this move the computation from about 17.5 second to about 4.8 seconds.

revlog: improve the robustness of the splitting process The previous "in-place" splitting, preserving the splitting on transaction failure had a couple of issue in case of transaction rollback: - a race windows that could still lead to a crash and data loss - it corrupted the `fncache`. So instead, we use a new approach that we summarized as "we do a backup of the inline revlog pre-split, and we restore this in case of failure". To make readers live easier, we don't overwrite the inline index file until transaction finalization. (once the transaction get into its finalization phase, it is not expected to rollback, unless some crash happens). To do so, we write the index of the split index in a temporary file that we use until transaction finalization. We also keep a backup of the initial inline file to be able to rollback the split if needed. As a result, transaction rollback cancel the split and no longer corrupt fncache. We also no longer have a small inconsistency windows where the transaction could be unrecoverable.

fncache: make it possible to ignore some file In the next changeset, we need to able to ignore some temporary file. This changeset teach the fncache about that.

revlog: test that pending hooks properly see the repository on split This seems important to explicitly cover this case before changing the code.

revlog: test possible read race condition with splitting This is currently working fine, but could break with another approach (for example, with the one we are about to use in the next changesets…) So we make sure the case is covered.

revlog: add a failing variant of the the split + transaction test We have another variant to tests, and it is crashing… So lets cover it with tests.

revlog: update the split + transaction test We add section, increase the amount of comments and simplify some of the constructs. We are about to build more on top this tests so lets do a small cleanup first.

transaction: allow to backup file that already have an offset This will be useful in the next changeset to deal with rolling back the split of inline revlog on transaction failure. This involve deeper change to the transaction logic as we need to make sure we restore the backup -before- the truncation step. Otherwise, the truncation would act on the wrong file and be overwritten by the backup restoration later.

transaction: move the restoration of backup file in a small closure We are about to use that logic in two different location, making is a small reusable closure prepares that.

transaction: raise on backup restoration error A few line above, similar errors in the truncation code result in raising the associated exception. We should do the same here. This means the transaction recover is more strict now, which might be a problem when running `hg recover` in a share different from the one where the transaction fails. However this has always been a problem and need to be be addressed independently.

transaction: add clarifying comment about why ignoring some error is fine It is less scary when explained.

transaction: properly clean up backup file outside of .hg/store/ Oops.

statprof: with Python 3.12, lineno is (more) often None test-profile.t failed with errors like: TypeError: %d format: a real number is required, not NoneType statprof.py already handled None values as -1 in some cases. Do the same in more cases.

py3: fix for Python 3.12 emitting SyntaxWarning on invalid escape sequences Mercurial became very noisy after https://github.com/python/cpython/commit/a60ddd31be7ff96a8189e7483bf1eb2071d2bddf , for example: $ python3.12 mercurial/store.py mercurial/store.py:406: SyntaxWarning: invalid escape sequence '\.' EXCLUDED = re.compile(b'.*undo\.[^/]+\.(nd?|i)$') This verbosity made some tests fail. The problems were mostly insufficiently escaped regexps, relying on the Python parser/scanner preserving invalid escape sequences.

cext: fix for PyLong refactoring in CPython 3.12 Compiling Mercurial with Python 3.12 a5 would fail with: mercurial/cext/dirs.c: In function '_addpath': mercurial/cext/dirs.c:19:44: error: 'PyLongObject' {aka 'struct _longobject'} has no member named 'ob_digit' 19 | #define PYLONG_VALUE(o) ((PyLongObject *)o)->ob_digit[0] | ^~ mercurial/cext/dirs.c:97:25: note: in expansion of macro 'PYLONG_VALUE' 97 | PYLONG_VALUE(val) += 1; | ^~~~~~~~~~~~ mercurial/cext/dirs.c:19:44: error: 'PyLongObject' {aka 'struct _longobject'} has no member named 'ob_digit' 19 | #define PYLONG_VALUE(o) ((PyLongObject *)o)->ob_digit[0] | ^~ mercurial/cext/dirs.c:108:17: note: in expansion of macro 'PYLONG_VALUE' 108 | PYLONG_VALUE(val) = 1; | ^~~~~~~~~~~~ mercurial/cext/dirs.c: In function '_delpath': mercurial/cext/dirs.c:19:44: error: 'PyLongObject' {aka 'struct _longobject'} has no member named 'ob_digit' 19 | #define PYLONG_VALUE(o) ((PyLongObject *)o)->ob_digit[0] | ^~ mercurial/cext/dirs.c:145:23: note: in expansion of macro 'PYLONG_VALUE' 145 | if (--PYLONG_VALUE(val) <= 0) { | ^~~~~~~~~~~~ This was caused by https://github.com/python/cpython/commit/c1b1f51cd1632f0b77dacd43092fb44ed5e053a9 .

histedit: fix diff colors The problem here is that indexing a bytestring gives you integers, not chars, so the comparison to b'+' ends up being wrong. We don't really have a way to test curses output, so no tests to verify the correctness of this behaviour.

dirstate: fix a potential traceback when in `copy` and `rename` Before this changes, calling `hg copy` or `hg rename` could trigger a traceback about using an invalidated dirstate. This wasn't caught by the test as it needed the blackbox extension to preload the dirstate first in a way "refresh" invalidates it. Changing the context creation patterns fixes it.

dirstate: fix the bug in [status] dealing with committed&ignored directories In particular, these directories can "infect" their sibling directories with ignored status due to using a shared memoization cell by accident. This fixes bug #6795.

tests: demonstrate a bug with committed&ignored dirs

rust: remove out-of-date comment We've migrated to a newer version of Rust, so it doesn't make sense anymore.