Gregory Szorc <gregory.szorc@gmail.com> [Thu, 14 Mar 2019 18:25:23 -0700] rev 41960
wix: package missing .dll and .pyd files
dist.wxs is currently missing some .pyd and .dll files which are
picked up and staged by py2exe. This means that the WiX installer
is missing some Python extension modules and their dependencies which
are referenced by Mercurial or a Python package distributed with
it.
This commit adds the missing files to the WiX installer.
Differential Revision: https://phab.mercurial-scm.org/D6137
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 14 Mar 2019 18:25:07 -0700] rev 41959
setup: exclude crypt32.dll in py2exe builds
py2exe is picking up crypt32.dll as a dependency and is including
the DLL in the dist/lib directory, where it can get picked up by an
installer and distributed.
crypt32.dll is a core Windows DLL since Windows XP. We don't need
to distribute it.
Differential Revision: https://phab.mercurial-scm.org/D6136
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 14 Mar 2019 13:27:37 -0700] rev 41958
packaging: don't bundle DLLs in py2exe library.zip for x86 builds
I had ported the x86/x64 behavior difference from the Inno
Setup installer files. Why things were this way, I'm not sure.
The WiX configuration files are expecting to have standalone
DLL files for both configurations. And the 32-bit WiX installers
were broken due to missing DLLs.
Let's standardize on standalone DLL files on all configurations
for consistency. I /think/ this will be faster, as I /think/
py2exe binaries would have to extract the DLL to a temporary file
in order to load it. But I'm not 100% sure about that.
Differential Revision: https://phab.mercurial-scm.org/D6135
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 14 Mar 2019 18:14:33 -0700] rev 41957
packaging: convert files to LF
My editor accidentally wrote CRLF line endings because I authored
this code on Windows. Derp.
I'm kinda surprised no linters caught this...
# no-check-commit to avoid false positive for foo_bar names
Differential Revision: https://phab.mercurial-scm.org/D6134
Martin von Zweigbergk <martinvonz@google.com> [Wed, 13 Mar 2019 10:51:40 -0700] rev 41956
dirstate: remove obsolete reference to dirstate.beginparentchange
The only valid API since 265e91da56fd (dirstate: drop deprecated
methods (API), 2018-02-02) is the context manager returned from
dirstate.parentchange().
Differential Revision: https://phab.mercurial-scm.org/D6126
Ian Moody <moz-ian@perix.co.uk> [Sat, 09 Mar 2019 00:44:26 +0000] rev 41955
py3: use pycompat.iterbytestr to convert memoryview slice to bytestring
Otherwise ch is the int value of the byte in py3 rather than the actual
character.
Differential Revision: https://phab.mercurial-scm.org/D6103
Martin von Zweigbergk <martinvonz@google.com> [Thu, 14 Mar 2019 14:46:29 -0700] rev 41954
rebase: fix crash with in-memory rebase and copies
When using regular on-disk rebase, filectx.markcopies() calls to
dirstate.copy(), which happily records the copy. Then it's simply
ignored if it doesn't matter for the commit (as in the test case I
added in the previous patch). Let's do the same for overlayworkingctx.
Differential Revision: https://phab.mercurial-scm.org/D6133
Martin von Zweigbergk <martinvonz@google.com> [Thu, 14 Mar 2019 13:53:20 -0700] rev 41953
test: demonstrate crash with in-memory rebase and copies
In the added test case, there is a merge commit that has one obsolete
parent with a rename. Since the rename is not in the other parent,
pathcopies() from that other parent will include the copy. Then when
we try to rebase this merge commit onto another commit that has the
same content changes, but no tracking of the rename (because it was
done with "hg remove; hg add" instead of "hg mv"), we try to propagate
the copy information. That fails because overlayworkingctx expects a
file to be modified if it's going to have copy information.
Differential Revision: https://phab.mercurial-scm.org/D6132
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 14 Mar 2019 09:12:46 +0000] rev 41952
manifestcache: actually honor --clear
Before this change, the --clear flag was not clearing the on disk cache.
(We also remove the extra verbosity when using --clear. Same as what we did for --add)
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 14 Mar 2019 10:58:53 +0000] rev 41951
manifestcache: make sure the entry are ordered by access time
This is an LRU cache, let us make sure of that.