Sat, 01 Feb 2020 00:41:37 -0500 packaging: set the FileVersion field in the Inno installer executable stable
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
Sat, 01 Feb 2020 00:32:46 -0500 packaging: move the version normalization function to the util module stable
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
Fri, 31 Jan 2020 22:20:39 -0500 resourceutil: account for the non-resource-like file hierarchy under py2exe stable
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
Thu, 30 Jan 2020 19:37:06 -0500 wix: restore COPYING.rtf stable
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
Fri, 24 Jan 2020 12:50:27 +0100 contrib: a small script to nudge lingering diff
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.
Sun, 26 Jan 2020 16:23:57 -0800 packaging: add support for PyOxidizer
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
Wed, 29 Jan 2020 11:30:16 -0800 mergestate: add accessors for local and other nodeid, not just contexts
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
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -7 +7 +10 +30 +100 +300 +1000 +3000 tip