Sun, 28 Jun 2020 17:49:14 +0200 curses: back out d2227d4c9e6b (do not initialize LC_ALL to user settings)
Manuel Jacob <me@manueljacob.de> [Sun, 28 Jun 2020 17:49:14 +0200] rev 45017
curses: back out d2227d4c9e6b (do not initialize LC_ALL to user settings) The changeset was based on a25343d16ebe, which will be backed out, too. Another fix for the problem will be resubmitted to the stable branch.
Thu, 25 Jun 2020 11:22:34 +0200 test: redirect stderr so warning messages don't change output (issue6237)
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
Thu, 25 Jun 2020 12:02:34 -0700 locks: expect repo lock, not wlock, when writing to .hg/strip-backup/
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
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -3 +3 +10 +30 +100 +300 +1000 +3000 tip