Matt Harbison <matt_harbison@yahoo.com> [Sat, 01 Feb 2020 00:41:37 -0500] rev 44221
packaging: set the FileVersion field in the Inno installer executable
Previously, Properties > Details > File version showed "0.0.0.0". This appears
to be a longstanding issue, and not part of the refactoring this cycle.
Differential Revision: https://phab.mercurial-scm.org/D8060
Matt Harbison <matt_harbison@yahoo.com> [Sat, 01 Feb 2020 00:32:46 -0500] rev 44220
packaging: move the version normalization function to the util module
This will be used with Inno as well. Since this module isn't platform specific,
rename to include that this is meant for Windows. (Mac has a different format.)
Differential Revision: https://phab.mercurial-scm.org/D8059
Matt Harbison <matt_harbison@yahoo.com> [Fri, 31 Jan 2020 22:20:39 -0500] rev 44219
resourceutil: account for the non-resource-like file hierarchy under py2exe
After
9e367157a990, config files for py2exe were expected to be in
C:\Program Files\Mercurial\mercurial\defaultrc because of the implied resource
structure of 'mercurial.defaultrc.*.rc', relative to the executable.
Accomodating this would require changes to the WIX and Inno scripts (and perhaps
the script that generates the WIX script), as well as 3rd party bundlers like
TortoiseHg. But these files aren't read as resources anyway- they fall back to
the filesystem APIs. (If we really wanted to carry on the charade, the
installer would have to also sprinkle various empty __init__.py files around.)
Instead, this simply prunes the 'mercurial.' portion of the resource name when
run with py2exe. (PyOxidizer uses the resources API, not the filesystem
fallback, so it is unaffected.) Since this hack only affects the py2 Windows
installers and is less risky, I think it's reasonable. We haven't needed to
load any 3rd party resource up to this point, and would have to make packaging
changes anyway to handle that.
Differential Revision: https://phab.mercurial-scm.org/D8058
Matt Harbison <matt_harbison@yahoo.com> [Thu, 30 Jan 2020 19:37:06 -0500] rev 44218
wix: restore COPYING.rtf
This got truncated to 0 bytes in
0ab651b5f77c when the Phabricator extension
crashed because it's a binary file. That caused the license page in the WIX
installer to be empty. I don't remember if I needed to resubmit after the bug
was fixed, so let's try this again with the current stable. If this fails, I'll
retry with 5.1 to see if this is a regression in the API changeover last cycle.
Differential Revision: https://phab.mercurial-scm.org/D8052
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 24 Jan 2020 12:50:27 +0100] rev 44217
contrib: a small script to nudge lingering diff
After a discussion on IRC with various reviewers. It seems like a good idea to
have some automatic cleanup of old, inactive diffs.
Here is a small script able to do so. I am preparing to unleash it on our
phabricator instance.
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 26 Jan 2020 16:23:57 -0800] rev 44216
packaging: add support for PyOxidizer
I've successfully built Mercurial on the development tip of
PyOxidizer on Linux and Windows. It mostly "just works" on Linux.
Windows is a bit more finicky.
In-memory resource files are probably not all working correctly
due to bugs in PyOxidizer's naming of modules. PyOxidizer now
now supports installing files next to the produced binary. (We
do this for templates in the added file.) So a workaround
should be available.
Also, since the last time I submitted support for PyOxidizer,
PyOxidizer gained the ability to auto-generate Rust projects
to build executables. So we don't need to worry about vendoring
any Rust code to initially support PyOxidizer. However, at some
point we will likely want to write our own command line driver
that embeds a Python interpreter via PyOxidizer so we can run
Rust code outside the confines of a Python interpreter. But that
will be a follow-up.
I would also like to add packaging.py CLI commands to build
PyOxidizer distributions. This can come later, if ever.
PyOxidizer's new "targets" feature makes it really easy to define
packaging tasks in its Starlark configuration file. While not
much is implemented yet, eventually we should be able to produce
MSIs, etc using a `pyoxidizer build` one-liner. We'll get there...
Differential Revision: https://phab.mercurial-scm.org/D7450
Martin von Zweigbergk <martinvonz@google.com> [Wed, 29 Jan 2020 11:30:16 -0800] rev 44215
mergestate: add accessors for local and other nodeid, not just contexts
The mergestate can contain invalid nodeids. In that case,
`mergestate.localctx` or `mergestate.otherctx` will fail. This patch
provides a way of accessing the nodeid without failing in such cases.
Differential Revision: https://phab.mercurial-scm.org/D8040
Martin von Zweigbergk <martinvonz@google.com> [Wed, 15 Jan 2020 22:24:16 -0800] rev 44214
rebase: define base in only place in defineparents()
Just a little refactoring to prepare for the next patch.
Differential Revision: https://phab.mercurial-scm.org/D7906
Martin von Zweigbergk <martinvonz@google.com> [Fri, 20 Dec 2019 16:16:57 -0800] rev 44213
tests: use full `uncommit` command name in tests
I'm about to add a `hg uncopy`, so the `hg unc` we used for `hg
uncommit` would become ambiguous.
Differential Revision: https://phab.mercurial-scm.org/D8028
Martin von Zweigbergk <martinvonz@google.com> [Tue, 28 Jan 2020 14:53:23 -0800] rev 44212
graft: default `base` argument to common case of `ctx.p1()`
I also updated the callers that wanted that, partly to simplify and
partly to show that it works.
Differential Revision: https://phab.mercurial-scm.org/D8027