Antoine Cezar <antoine.cezar@octobus.net> [Mon, 10 Aug 2020 15:50:22 +0200] rev 45402
documentation: add `zstd` compression to the internal `revlogs` documentation
Differential Revision: https://phab.mercurial-scm.org/D8953
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 29 Aug 2020 14:35:18 +0530] rev 45401
extdiff: move single file handling inside `not per-file` conditional
If `--per-file` is passed, we will diffing files one by one, hence there is no
need to make this optimization around single file in that case. This
optimization is only required when `--per-file` is not passed and we will be
opening directory-diff for a single file.
Differential Revision: https://phab.mercurial-scm.org/D8971
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 29 Aug 2020 14:32:26 +0530] rev 45400
extdiff: remove dir2root and pass full path as dir2 in _runperfilediff()
The only use of `dir2root` was to join with `dir2` to generate the path for
other side of diff. Like in previous patch, `dir1a` and `dir1b` are full paths
and no longer base names, hence we pass `dir2` as full path too and making
`dir2root` unrequired.
Differential Revision: https://phab.mercurial-scm.org/D8970
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 29 Aug 2020 14:28:34 +0530] rev 45399
extdiff: pass full paths of `dir1a` and `dir1b` to `_runperfilediff()`
Earlier we were passing basename instead of the fullpath and then joining with
the tmproot. This is wrong because the user can choose `rev1a` as wdir and in
those cases, tmproot should not be joined with the path.
I am working on refactoring extdiff logic so that we can have options like `diff
--tool` and encountered this. Although this patch in itself makes no difference,
however in future when a new caller of `_runperfilediff()` will be added, it
will be useful to directly pass on the full paths instead.
Differential Revision: https://phab.mercurial-scm.org/D8969
Harald Klimach <harald@klimachs.de> [Wed, 02 Sep 2020 12:31:37 +0200] rev 45398
hgweb: compatibility of hgweb.cgi template with Python 3
When running Mercurial on Python 3 hgweb expects the config variable to be a
bytestring.
The solution proposed by Anton Shestakov is to use a byteprefix to the literal
string defined cgi script as provided in this patch for hgweb.cgi,
contrib/hgweb.fcgi and contrib/hgweb.wsgi.
I am not sure whether this covers all relevant templates, but I couldn't find
others.
Differential Revision: https://phab.mercurial-scm.org/D8978
Augie Fackler <augie@google.com> [Tue, 01 Sep 2020 10:33:10 -0400] rev 45397
genosxversion: don't give up if we can't find a path to hg libraries
This doesn't work if you have a PyOxidized hg on $PATH, but everything
is fine if you just ignore that problem.
Differential Revision: https://phab.mercurial-scm.org/D8975
Manuel Jacob <me@manueljacob.de> [Wed, 02 Sep 2020 01:30:56 +0200] rev 45396
tests: fix test-demandimport.py on Python 3.9
Starting with Python 3.9, importing importlib.resources (indirectly) imports
the zipfile module. Therefore, the module is not suitable for the test.
Instead, we can use the ftplib module, which is very unlikely to be imported
during the test run.
Augie Fackler <augie@google.com> [Tue, 01 Sep 2020 09:46:15 -0400] rev 45395
merge with stable
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 01 Sep 2020 16:27:25 +0530] rev 45394
Added signature for changeset
f62bb5d07848
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 01 Sep 2020 16:27:18 +0530] rev 45393
Added tag 5.5.1 for changeset
f62bb5d07848
Matt Harbison <matt_harbison@yahoo.com> [Mon, 24 Aug 2020 12:39:48 -0400] rev 45392
mercurial: force LF endings for *.py, *.{c,h} and *.t in .editorconfig
PyCharm on Windows otherwise uses CRLF.
Differential Revision: https://phab.mercurial-scm.org/D8947
Aay Jay Chan <aayjaychan@itopia.com.hk> [Tue, 18 Aug 2020 22:21:00 +0800] rev 45391
hooklib: update documentation of changeset_obsoletedfor for changed hook type
This updates usage example of changeset_obsoleted to reflect the move from
pretxnclose to txnclose made in
04ef381000a8 (hooklib: fix detection of
successors for changeset_obsoleted).
Differential Revision: https://phab.mercurial-scm.org/D8929
Martin von Zweigbergk <martinvonz@google.com> [Fri, 14 Aug 2020 20:45:49 -0700] rev 45390
worker: don't expose readinto() on _blockingreader since pickle is picky
The `pickle` module expects the input to be buffered and a whole
object to be available when `pickle.load()` is called, which is not
necessarily true when we send data from workers back to the parent
process (i.e., it seems like a bad assumption for the `pickle` module
to make). We added a workaround for that in
https://phab.mercurial-scm.org/D8076, which made `read()` continue
until all the requested bytes have been read.
As we found out at work after a lot of investigation (I've spent the
last two days on this), the native version of `pickle.load()` has
started calling `readinto()` on the input since Python 3.8. That
started being called in
https://github.com/python/cpython/commit/
91f4380cedbae32b49adbea2518014a5624c6523
(and only by the C version of `pickle.load()`)). Before that, it was
only `read()` and `readline()` that were called. The problem with that
was that `readinto()` on our `_blockingreader` was simply delegating
to the underlying, *unbuffered* object. The symptom we saw was that
`hg fix` started failing sometimes on Python 3.8 on Mac. It failed
very relyable in some cases. I still haven't figured out under what
circumstances it fails and I've been unable to reproduce it in test
cases (I've tried writing larger amounts of data, using different
numbers of workers, and making the formatters sleep). I have, however,
been able to reproduce it 3-4 times on Linux, but then it stopped
reproducing on the following few hundred attempts.
To fix the problem, we can simply remove the implementation of
`readinto()`, since the unpickler will then fall back to calling
`read()`. The fallback was added a bit later, in
https://github.com/python/cpython/commit/
b19f7ecfa3adc6ba1544225317b9473649815b38. However,
that commit also added checking that what `read()` returns is a
`bytes`, so we also need to convert the `bytearray` we use into
that. I was able to add a test for that failure at least.
Differential Revision: https://phab.mercurial-scm.org/D8928
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 27 Aug 2020 09:06:35 +0200] rev 45389
test: add `test-repo` requirement to `test-check-format` (
issue6395)
Kindly reported by Tristan Seligmann <mithrandi@mithrandi.net>
Martin von Zweigbergk <martinvonz@google.com> [Tue, 18 Aug 2020 15:03:57 -0700] rev 45388
commit: clear mergestate also with --amend (
issue6304)
The `hg commit --amend` uses the in-memory code, which naturally
doesn't touch the merge state (well, it shouldn't anyway; I think I've
fixed bugs in that area recently). We therefore need to clear the
mergestate after calling `repo.commitctx()` since we expect that from
`hg commit --amend`.
Differential Revision: https://phab.mercurial-scm.org/D8932
Martin von Zweigbergk <martinvonz@google.com> [Tue, 18 Aug 2020 14:26:49 -0700] rev 45387
tests: add test showing that merge state is not cleared by amend
This is slightly modified version of the test case I provided in
issue6304.
Differential Revision: https://phab.mercurial-scm.org/D8931