Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 29 Jan 2021 11:42:27 +0100] rev 46420
config: add a test for priority when includes are involved
Differential Revision: https://phab.mercurial-scm.org/D9915
Martin von Zweigbergk <martinvonz@google.com> [Fri, 29 Jan 2021 16:26:53 -0800] rev 46419
errors: use InputError for incorrectly formatted dates
Differential Revision: https://phab.mercurial-scm.org/D9913
Martin von Zweigbergk <martinvonz@google.com> [Fri, 29 Jan 2021 15:56:08 -0800] rev 46418
errors: use StateError more in merge module
Differential Revision: https://phab.mercurial-scm.org/D9912
Martin von Zweigbergk <martinvonz@google.com> [Fri, 29 Jan 2021 12:16:55 -0800] rev 46417
errors: use exit code 40 for when a hook fails
A hook can be used for checking inputs, state, configuration,
security, etc., so it's unclear which of the existing exit codes to
use. Let's instead add one specifically for failed hooks. I picked 40.
Differential Revision: https://phab.mercurial-scm.org/D9910
Augie Fackler <augie@google.com> [Fri, 29 Jan 2021 12:50:10 -0500] rev 46416
context: add missing manifest invalidation after write in overlayworkingctx
This was breaking my merge-diff logic that will be in the next patch.
Differential Revision: https://phab.mercurial-scm.org/D9908
Kyle Lippincott <spectral@google.com> [Wed, 27 Jan 2021 10:29:21 -0800] rev 46415
wix: tell ComponentSearch that it is finding a directory (not a file)
This is to fix an issue we've noticed where fresh installations start at
`C:\Program Files\Mercurial`, and then upgrades "walk up" the tree and end up in
`C:\Program Files` and finally `C:\` (where they stay).
ComponentSearch defaults to finding files, which I think means "it produces a
string like `C:\Program Files\Mercurial`", whereas with the type being
explicitly a directory, it would return `C:\Program Files\Mercurial\` (note the
final trailing backslash). Presumably, a latter step then tries to turn that
file name into a proper directory, by removing everything after the last `\`.
This could likely also be fixed by actually searching for the component for
hg.exe itself. That seemed a lot more complicated, as the GUID for hg.exe isn't
known in this file (it's one of the "auto-derived" ones). We could also consider
adding a Condition that I think could check the Property and ensure it's either
empty or ends in a trailing slash, but that would be an installer runtime check
and I'm not convinced it'd actually be useful.
This will *not* cause existing installations that are in one of the bad
directories to fix themselves. Doing that would require a fair amount more
understanding of wix and windows installer than I have, and it *probably*
wouldn't be possible to be 100% correct about it either (there's nothing
preventing a user from intentionally installing it in C:\, though I don't know
why they would do so).
If someone wants to tackle fixing existing installations, I think that the first
installation is actually the only one that shows up in "Add or Remove Programs",
and that its registry keys still exist. You might be able to find something
under HKEY_USERS that lists both the "good" and the "bad" InstallDirs. Mine was
under `HKEY_USERS\S-1-5-18\Software\Mercurial\InstallDir` (C:\), and
`HKEY_USERS\S-1-5-21-..numbers..\Software\Mercurial\InstallDir` (C:\Program
Files\Mercurial). If you find exactly two, with one being the default path, and
the other being a prefix of it, the user almost certainly hit this bug :D
We had originally thought that this bug might be due to unattended
installations/upgrades, but I no longer think that's the case. We were able to
reproduce the issue by uninstalling all copies of Mercurial I could find,
installing one version (it chose the correct location), and then starting the
installer for a different version (higher or lower didn't matter). I did not
need to deal with an unattended or headless installation/upgrade to trigger the
issue, but it's possible that my system was "primed" for this bug to happen
because of a previous unattended installation/upgrade.
Differential Revision: https://phab.mercurial-scm.org/D9891
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 29 Jan 2021 17:32:09 +0530] rev 46414
merge with stable
Matt Harbison <matt_harbison@yahoo.com> [Wed, 27 Jan 2021 00:54:57 -0500] rev 46413
copyright: update to 2021
Differential Revision: https://phab.mercurial-scm.org/D9885
Simon Sapin <simon.sapin@octobus.net> [Thu, 28 Jan 2021 13:15:34 +0100] rev 46412
persistent-nodemap: Fix Rust declarations for Revlog_CAPI signatures
Use Rust’s `libc::ssize_t` as the closest match to C’s `Py_ssize_t`.
See details in test comment.
Going forward we should find a way to have such Rust declarations
auto-generated from C headers at build time,
or auto-checked against them in a test.
Differential Revision: https://phab.mercurial-scm.org/D9901
Simon Sapin <simon.sapin@octobus.net> [Thu, 28 Jan 2021 13:25:37 +0100] rev 46411
persistent-nodemap: add test case reproducing a Rust panic
Thanks to Mitchell Plamann for reporting this bug.
The next commit fixes it.
Differential Revision: https://phab.mercurial-scm.org/D9900
Martin von Zweigbergk <martinvonz@google.com> [Thu, 28 Jan 2021 00:14:15 -0800] rev 46410
copies: fix an incorrect comment in graftcopies() from recent D9802
I don't think the bit about creating a merge in the filelog was
correct. Or at least I couldn't find a case where it happened.
Differential Revision: https://phab.mercurial-scm.org/D9899
Martin von Zweigbergk <martinvonz@google.com> [Wed, 27 Jan 2021 22:10:57 -0800] rev 46409
narrow: delete a stale TODO about not sending groups the client already has
2c5835b4246b changed the changegroup generation to not send
treemanifests for directories the client had before widening. As that
commit mentions, we had already stopped before that commit to send the
changelog and filelogs for files the client already had.
Differential Revision: https://phab.mercurial-scm.org/D9898
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 16 Jan 2021 00:03:18 +0100] rev 46408
copies: add an devel option to trace all files
Filelog based copy tracing only trace copy for file that have been added. This
is a trade off between skipping some rare copy case in exchange for avoiding
atrocious-to-the-point-of-unusable performance.
The changeset centric copy tracing does not need this trade off and naturally
trace all copy, include the one involving non-new files.
In order to ease the comparison from both algorithm, we add a small devel option
to trace copy for all files in the target revisions.
Differential Revision: https://phab.mercurial-scm.org/D9796
Raphaël Gomès <rgomes@octobus.net> [Thu, 28 Jan 2021 15:26:33 +0100] rev 46407
revlog: prepare pure parser for being overloaded
The current class uses module-level variables which don't allow for reusing the
current logic for a slightly different revlog version.
Differential Revision: https://phab.mercurial-scm.org/D9903
Raphaël Gomès <rgomes@octobus.net> [Thu, 28 Jan 2021 15:12:48 +0100] rev 46406
revlog: use a less probable revlog version for backwards compatibility
This allows us to define a usable v2.
Differential Revision: https://phab.mercurial-scm.org/D9902