Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Mar 2023 14:29:37 +0100] rev 50340
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.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Mar 2023 13:20:12 +0100] rev 50339
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.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Mar 2023 12:13:08 +0100] rev 50338
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.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Mar 2023 12:08:05 +0100] rev 50337
transaction: add clarifying comment about why ignoring some error is fine
It is less scary when explained.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Mar 2023 11:18:24 +0100] rev 50336
transaction: properly clean up backup file outside of .hg/store/
Oops.
Raphaël Gomès <rgomes@octobus.net> [Mon, 20 Mar 2023 23:16:14 +0100] rev 50335
branching: merge stable into default
Mads Kiilerich <mads@kiilerich.com> [Tue, 07 Mar 2023 17:13:38 +0100] rev 50334
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.
Mads Kiilerich <mads@kiilerich.com> [Tue, 07 Mar 2023 16:45:54 +0100] rev 50333
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.
Mads Kiilerich <mads@kiilerich.com> [Tue, 07 Mar 2023 16:25:51 +0100] rev 50332
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 .
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Thu, 27 Oct 2022 17:34:02 -0400] rev 50331
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.