Julien Cristau <jcristau@debian.org> [Thu, 25 Jun 2020 11:22:34 +0200] rev 45016
test: redirect stderr so warning messages don't change output (
issue6237)
clone and commit race for the lock, and if commit has to wait more than
a second it prints a warning to stderr. Since this is somewhat expected
here, silence it.
Differential Revision: https://phab.mercurial-scm.org/D8664
Martin von Zweigbergk <martinvonz@google.com> [Thu, 25 Jun 2020 12:02:34 -0700] rev 45015
locks: expect repo lock, not wlock, when writing to .hg/strip-backup/
There should be no need for a working copy lock when creating (or
reading) bundles in `.hg/strip-backup/` since they don't affect the
working copy.
I noticed this because we have an extension that tries to strip some
revisions while holding only a repo lock. I guess we have no such
cases in core, which seems a bit surprising. Maybe we always take a
wlock at a higher level so the working copy is not updated while the
target commit is being stripped.
Differential Revision: https://phab.mercurial-scm.org/D8666
Martin von Zweigbergk <martinvonz@google.com> [Thu, 25 Jun 2020 13:37:56 -0700] rev 45014
graft: leverage cmdutil.check_incompatible_arguments() for --abort/--stop
Differential Revision: https://phab.mercurial-scm.org/D8669
Manuel Jacob <me@manueljacob.de> [Mon, 29 Jun 2020 02:05:12 +0200] rev 45013
run-tests: fix escapes with conditions
Before this fix, escapes with conditions in tests failed like this on Python 3:
$ $PYTHON -c 'from mercurial.utils.procutil import stdout; stdout.write(b"\xff")'
- \xff (no-eol) (esc) (true !)
+ \xff (no-eol) (esc)
The unicode_escape encoding decodes br'\xff' to u'\xff'. To convert the first
256 code points to bytes with the same ordinal, the latin-1 encoding must be
used.
Escapes without conditions already worked before on Python 3, but not through
`el == l` a few lines below the changed line in run-tests.py. I didn’t
investigate further.
Manuel Jacob <me@manueljacob.de> [Sun, 28 Jun 2020 18:02:45 +0200] rev 45012
convert: set LC_CTYPE around calls to Subversion bindings
The Subversion bindings require that LC_CTYPE is set. However, we don’t want to
set it all the time, as it changes the behavior of str methods on Python 2. The
taken approach is hopefully fine-grained enough to not trigger any
locale-specfic behavior of the str methods and coarse-grained enough to not
clutter the code.
Emulating the with-statement behavior in before() and after() should be safe, as
after() is always called when before() is called. hgext.convert.hg takes a
similar approach.
Manuel Jacob <me@manueljacob.de> [Sun, 28 Jun 2020 18:02:45 +0200] rev 45011
curses: do not initialize LC_ALL to user settings (
issue6358)
701341f57ceb moved the setlocale() call to right before curses was used. This
didn’t fully solve the problem it was supposed to solve (locale-dependent
functions, like date formatting/parsing and str methods on Python 2), but only
postponed it.
Initializing LC_CTYPE seems to be sufficient for curses to work correctly.
Therefore LC_CTYPE is set while curses is used and reset afterwards. Some
locale-dependent str methods might behave differently on Python 2 while curses
is used, but that shouldn’d be a problem.
Martin von Zweigbergk <martinvonz@google.com> [Thu, 25 Jun 2020 13:29:05 -0700] rev 45010
graft: leverage cmdutil.check_incompatible_arguments() for --no-commit
Differential Revision: https://phab.mercurial-scm.org/D8668
Martin von Zweigbergk <martinvonz@google.com> [Thu, 25 Jun 2020 13:27:37 -0700] rev 45009
graft: leverage cmdutil.check_at_most_one_arg() for --abort/--stop/--continue
Differential Revision: https://phab.mercurial-scm.org/D8667
Matt Harbison <matt_harbison@yahoo.com> [Sat, 27 Jun 2020 21:45:20 -0400] rev 45008
version: sort extensions by name in verbose mode
External extensions can be assigned any name, but presumably most enabled
extensions will be internal ones and having them sorted makes it easier to find
specific ones if the list is long. The lists in `hg help extensions` are
already sorted.
Differential Revision: https://phab.mercurial-scm.org/D8671
Manuel Jacob <me@manueljacob.de> [Sat, 27 Jun 2020 20:19:41 +0200] rev 45007
crecord: stop trying to import wcurses
The original import of crecord in 2008 already said "I have no idea if wcurses
works with crecord...".
The last reference to a Python package called wcurses is
https://web.archive.org/web/
20101025073658/http://adamv.com/dev/python/curses/.
However, the Python package from there is called "curses" and not "wcurses".
I didn’t find any evidence that it ever worked.