Thu, 05 Dec 2019 14:28:21 -0800 chg: fix chg to work with py3.7+ "coercing" the locale
Kyle Lippincott <spectral@google.com> [Thu, 05 Dec 2019 14:28:21 -0800] rev 43860
chg: fix chg to work with py3.7+ "coercing" the locale When the environment is empty (specifically: it doesn't contain LC_ALL, LC_CTYPE, or LANG), Python will "coerce" the locale environment variables to be a UTF-8 capable one. It sets LC_CTYPE in the environment, and this breaks chg, since chg operates by: - start hg, using whatever environment the user has when chg starts - hg stores a hash of this "original" environment, but python has already set LC_CTYPE even though the user doesn't have it in their environment - chg calls setenv over the commandserver. This clears the environment inside of hg and sets it to be exactly what the environment in chg is (without LC_CTYPE). - chg calls validate to ensure that the environment hg is using (after the setenv call) is the one that the chg process has - if not, it is assumed the user changed their environment and we should use a different server. This will *never* be true in this situation because LC_CTYPE was removed. Differential Revision: https://phab.mercurial-scm.org/D7550
Mon, 09 Dec 2019 22:20:35 -0500 fuzz: add support for fuzzing under either Python 2 or 3
Augie Fackler <augie@google.com> [Mon, 09 Dec 2019 22:20:35 -0500] rev 43859
fuzz: add support for fuzzing under either Python 2 or 3 This was more of a hairball than I hoped, but it appears to work. The hg-py3 branch of my oss-fuzz fork on github has the remaining changes to switch us to Python 3, but we may as well retain Python 2 fuzzing support for at least a little while. Differential Revision: https://phab.mercurial-scm.org/D7592
Fri, 22 Nov 2019 23:43:59 -0500 phabricator: color the status in the "phabstatus" view
Matt Harbison <matt_harbison@yahoo.com> [Fri, 22 Nov 2019 23:43:59 -0500] rev 43858
phabricator: color the status in the "phabstatus" view I couldn't figure out strikethrough for "abandoned" like I've see with word diff. Differential Revision: https://phab.mercurial-scm.org/D7608
Wed, 11 Dec 2019 23:16:42 -0500 phabricator: add the "Changes Planned" status name
Matt Harbison <matt_harbison@yahoo.com> [Wed, 11 Dec 2019 23:16:42 -0500] rev 43857
phabricator: add the "Changes Planned" status name I noticed this when coloring the status output. But it looks like status names are also used in the pseudo revset language as well, and abort when parsing a name not in this list. Differential Revision: https://phab.mercurial-scm.org/D7607
Wed, 11 Dec 2019 15:23:54 -0800 fuzz: fix mpatch_corpus to not have an overridden __repr__ on py3
Kyle Lippincott <spectral@google.com> [Wed, 11 Dec 2019 15:23:54 -0800] rev 43856
fuzz: fix mpatch_corpus to not have an overridden __repr__ on py3 Differential Revision: https://phab.mercurial-scm.org/D7606
Wed, 11 Dec 2019 10:00:24 -0800 formatting: fix some recent formatting regressions
Martin von Zweigbergk <martinvonz@google.com> [Wed, 11 Dec 2019 10:00:24 -0800] rev 43855
formatting: fix some recent formatting regressions Differential Revision: https://phab.mercurial-scm.org/D7605
Mon, 09 Dec 2019 12:29:46 +0100 remotefilelog: remove the `ensurestart` usage stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 09 Dec 2019 12:29:46 +0100] rev 43854
remotefilelog: remove the `ensurestart` usage The option does not seems to do what we want since it does not wait on the background process actually starting (eg: taking the lock). And the race have been dealt with another way anyway. This effectively back out changeset 2c74337e6483. Differential Revision: https://phab.mercurial-scm.org/D7590
Mon, 09 Dec 2019 11:26:53 +0100 remotefilelog: remove most of the debugwait* command in the tests stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 09 Dec 2019 11:26:53 +0100] rev 43853
remotefilelog: remove most of the debugwait* command in the tests Since we use a dedicated developer config, we do not need them anymore. Differential Revision: https://phab.mercurial-scm.org/D7589
Mon, 09 Dec 2019 11:45:17 +0100 remotefilelog: use the correct redirection in tests stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 09 Dec 2019 11:45:17 +0100] rev 43852
remotefilelog: use the correct redirection in tests The test were using '2>%1' which just redirect stderr in the "%1" file. The intend was '2>&1' which redirect stderr on stdin. This impact tests because some commit were picking up this '%1' files. Differential Revision: https://phab.mercurial-scm.org/D7588
Mon, 09 Dec 2019 10:09:40 +0100 remotefilelog: remove most sleep in tests stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 09 Dec 2019 10:09:40 +0100] rev 43851
remotefilelog: remove most sleep in tests Now that we removed most of the races, we can remove the infamous sleeps. Differential Revision: https://phab.mercurial-scm.org/D7587
Mon, 09 Dec 2019 09:57:34 +0100 remotefilelog: have command wait for background task in the tests stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 09 Dec 2019 09:57:34 +0100] rev 43850
remotefilelog: have command wait for background task in the tests We leverage the feature introduced in the two previous commit to have the main command wait for the background task to be finished before returning. All test still pass and instability seems to have gone away. Most of the sleep and explicit wait are now useless and will be cleaned up in later changesets. Differential Revision: https://phab.mercurial-scm.org/D7586
Mon, 09 Dec 2019 09:54:27 +0100 remotefilelog: add a developer option to wait for background processes stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 09 Dec 2019 09:54:27 +0100] rev 43849
remotefilelog: add a developer option to wait for background processes In order to block the main command on the subprocess exiting, we ensure the repo's ui object will call the subprocess.wait() method to ensure the top-level hg process doesn't exit until all background processes have also done so. Currently, in the tests, most operation spawning background process as followed by commands waiting for these operations to complete. However this waiting is racy. First because it seems like we can start waiting before the background operation actually start, in which case it is prematurely detected as "done". Second, because some commands may spawn multiple background operation for the same operation (eg: rebase can apparently trigger multiple prefetch). The current approach could be updated to maybe handle the first issue, but the second one will never be properly handled. In most case, we do not care that the bg process keep running after the command end. (Since we explicitly wait for them to end before doing anything else). So we add an option to wait on the background process before exiting the command. We'll put it in use in the next changeset. Differential Revision: https://phab.mercurial-scm.org/D7585
Mon, 09 Dec 2019 09:53:43 +0100 procutil: add a option to not fully detach background process stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 09 Dec 2019 09:53:43 +0100] rev 43848
procutil: add a option to not fully detach background process When writing test, it is useful to make code pretending to spawn a fully detached process while still actually waiting for it to finish. We add the option to `procutil.runbgcommand`, to do so. We will use this in remote-filelog tests. Differential Revision: https://phab.mercurial-scm.org/D7584
Thu, 05 Dec 2019 20:41:23 +0100 cext-revlog: fixed __delitem__ for uninitialized nodetree
Georges Racinet <georges.racinet@octobus.net> [Thu, 05 Dec 2019 20:41:23 +0100] rev 43847
cext-revlog: fixed __delitem__ for uninitialized nodetree This is a bug in a code path that's seldom used, because in practice (at least in the whole test suite), calls to `del index[i:j]` currently just don't happen before the nodetree has been initialized. However, in our current work to replace the nodetree by a Rust implementation, this is of course systematic. In `index_slice_del()`, if the slice start is smaller than `self->length`, the whole of `self->added` has to be cleared. Before this change, the clearing was done only by the call to `index_invalidate_added(self, 0)`, that happens only for initialized nodetrees. Hence the removal was effective only from `start` to `self->length`. The consequence is index corruption, with bogus results in subsequent calls, and in particular errors such as `ValueError("parent out of range")`, due to the fact that parents of entries in `self->added` are now just invalid. This is detected by the rebase tests, under conditions that the nodetree of revlog.c is never initialized. The provided specific test is more direct. Differential Revision: https://phab.mercurial-scm.org/D7603
Wed, 20 Nov 2019 13:03:22 -0500 filemerge: fix a missing attribute usage
Matt Harbison <matt_harbison@yahoo.com> [Wed, 20 Nov 2019 13:03:22 -0500] rev 43846
filemerge: fix a missing attribute usage Flagged by both pytype and VSCode. Differential Revision: https://phab.mercurial-scm.org/D7465
(0) -30000 -10000 -3000 -1000 -300 -100 -15 +15 +100 +300 +1000 +3000 tip