Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 06 Nov 2019 14:13:19 +0100] rev 43523
utils: move the `dirs` definition in pathutil (API)
Before this change, the `dirs` class was accessible through the `mercurial.util`
module. That module is expected to stay free of scm specific content.
The `pathutil` destination has been selection by Martin von Zweigbergk.
This work is part of a refactoring to unify the revlog index and the nodemap.
This unification prepare the use of a persistent nodemap.
Differential Revision: https://phab.mercurial-scm.org/D7311
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 23 Oct 2019 12:15:42 -0700] rev 43522
packaging: stop installing i18n files
The WiX installer has been shipping the content of the i18n/
directory since it was introduced in 2010 in
1e022c88a0a5.
And the installer was subsequently refactored to only ship
the .po files and hggettext.
The .po files and the hggettext script are only used at build
time to produce .mo files, which Mercurial does use at run-time.
It doesn't make sense to install these files on Windows. So
this commit stops doing that.
This change further converges the file layout of the Inno and
WiX installers.
Differential Revision: https://phab.mercurial-scm.org/D7165
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 23 Oct 2019 11:54:22 -0700] rev 43521
packaging: install hgk as hgk.tcl
Giving it a file extension will give Windows a better chance
at being able to execute it via standard means. This also
makes WiX consistent with the Inno installer.
Differential Revision: https://phab.mercurial-scm.org/D7164
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 23 Oct 2019 12:01:31 -0700] rev 43520
packaging: add logo-droplets.svg
The WiX installer adds this file. Let's add it to the
Inno installer for consistency.
Differential Revision: https://phab.mercurial-scm.org/D7163
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 23 Oct 2019 11:40:59 -0700] rev 43519
packaging: install documentation to doc/ directory
The source directory is "doc" and "doc" is used by the WiX
installer. I think it makes sense to converge on the canonical
path name. While we're here, we also lower the case because
we can. (I think lower case names make more sense plus it is
more consistent.)
This only affects the Inno installer at the moment because
it is the only installer using the staging code.
Differential Revision: https://phab.mercurial-scm.org/D7162
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 22 Oct 2019 18:34:03 -0700] rev 43518
packaging: always pass VERSION into Inno invocation
The code in the Inno file was a holdover from before we had
Python driving execution.
With Python in the driver's seat, we can now have it resolve
the version string and pass it into Inno, making the code
easier to understand for people who aren't packaging gurus.
Differential Revision: https://phab.mercurial-scm.org/D7161
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 24 Oct 2019 21:22:08 -0700] rev 43517
packaging: remove hg.exe.local file
<exe>.local files are used by Windows to set up DLL
redirection. But these files are ignored if you embed an
application manifest in your binary, which we do.
So the existence of this file serves no purpose. So we remove
it.
Differential Revision: https://phab.mercurial-scm.org/D7160
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 23 Oct 2019 18:39:28 -0700] rev 43516
packaging: stage installed files for Inno
Previously, the Inno installer maintained its own mapping of
source files to install location. (We have to maintain a
similar mapping in the WiX installer.)
Managing the explicit file layout for Windows packages is
cumbersome and redundant. Every time you want to change the
layout you need to change N locations. We frequently forget
to do this and we only find out when people install Mercurial
from our packages at release time.
This commit starts the process of consolidating and simplifying
the logic for managing the install layout on Windows.
We introduce a list of install layout rules. These are simply
source filenames (which can contain wildcards) and destination
paths.
The Inno packaging code has been updated to assemble all
files into a staging directory that mirrors the final install
layout. The list of files to add to the installer is derived
by walking this staging directory and dynamically emitting
the proper entries for the Inno Setup script.
I diffed the file layout before and after this commit and
there is no difference.
Another benefit of this change is that it facilitates easier
testing of the Windows install layout. Before, in order to
test the final install layout, you needed to build an installer
and run it. Now, you can stage files into the final layout
and test from there, without running the installer. This
should cut down on overhead when changing Windows code.
Differential Revision: https://phab.mercurial-scm.org/D7159
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 23 Oct 2019 18:39:17 -0700] rev 43515
packaging: process Inno Setup files with Jinja2
I want to make the Inno Setup files dynamically generated.
This will enable us to do things like automatically derive the
set of files to be packaged instead of having to manually
keep lists of files in sync across installers.
As the first step towards this, we process the Inno Setup
files with Jinja2.
As part of this conversion, we had to escape syntax in
mercurial.iss that conflicts with Jinja2. I also took the
opportunity to include modpath.iss via Jinja2 instead of
using Inno's preprocessor. This keeps the Python code a
bit simpler.
Differential Revision: https://phab.mercurial-scm.org/D7158
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 23 Oct 2019 18:39:08 -0700] rev 43514
packaging: install and run Inno files in a build directory
Upcoming commits will refactor the Windows installers so their
content is dynamically derived. In preparation for this, we
copy the Inno files into a new build directory and run them
from there. This required changing some relative paths to
work from a new directory level but is otherwise a pretty
straightforward change.
Differential Revision: https://phab.mercurial-scm.org/D7157
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 23 Oct 2019 18:37:36 -0700] rev 43513
packaging: consolidate CLI functionality into packaging.py
Consolidating functionality for invoking code in the hgpackaging
package through a single CLI entry point will make things simpler
when we add more complexity to that package. For example, it will
allow us to run things out of a virtualenv with third party
packages.
This commit consolidates functionality from the Inno and WiX
build.py scripts into a new packaging.py script. That script
simply creates a virtualenv and runs the CLI functionality in
it.
The new virtualenv is populated with jinja2 because I felt
it easier to incorporate requirements file processing in this
commit and we will soon use jinja2 in an upcoming commit.
The unified CLI functionality will also make it easier to
script other packaging workflows going forward. e.g. RPM, Debian,
and macOS packaging.
Differential Revision: https://phab.mercurial-scm.org/D7156
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 23 Oct 2019 18:30:22 -0700] rev 43512
packaging: clean up excess packages for Inno
This partially reverts
e97ffa5511ba.
A bunch of package dependencies were getting picked up because
I ran pip-compile on Linux and the keyring package has some
Linux-only dependencies.
I have run pip-compile again - this time from Windows - to undo
the addition of these dependencies. I also normalized whitespace
to LF.
Differential Revision: https://phab.mercurial-scm.org/D7155
Kyle Lippincott <spectral@google.com> [Fri, 08 Nov 2019 14:21:52 -0800] rev 43511
unshelve: correct help string; unshelve does not accept file list
The non-option arguments to `hg unshelve` are interpreted as the name of the
shelve to unshelve, not the list of files to unshelve. While that functionality
would probably be nice to have, that's well beyond the scope of this
documentation fix.
Differential Revision: https://phab.mercurial-scm.org/D7365
Martin von Zweigbergk <martinvonz@google.com> [Fri, 08 Nov 2019 11:23:22 -0800] rev 43510
repoview: use class literal for creating filteredchangelog
The type name is constant, so we don't need to create it dynamically
using type(). As suggested by Yuya.
Differential Revision: https://phab.mercurial-scm.org/D7364
Augie Fackler <augie@google.com> [Thu, 07 Nov 2019 14:59:11 -0500] rev 43509
vagrant: update vagrant image to buster from jessie
I honestly have no idea if this works since I don't use vagrant, but
looking around online suggests it should work fine.
Differential Revision: https://phab.mercurial-scm.org/D7309