Navaneeth Suresh <navaneeths1998@gmail.com> [Mon, 04 Mar 2019 20:18:13 +0530] rev 41865
uncommit: add flag --allow-dirty-working-copy
This adds a flag `--allow-dirty-working-copy` as an alias for
the experimental config option `experimental.uncommitondirtydir`.
Differential Revision: https://phab.mercurial-scm.org/D6069
Navaneeth Suresh <navaneeths1998@gmail.com> [Tue, 12 Feb 2019 00:17:42 +0530] rev 41864
uncommit: don't allow dirty working copy with PATH (issue5977)
On a dirty PATH, uncommit was working without even setting the config
`experimental.uncommitondirtydir` to `True`. Ideally, it should abort
as it does for a dirty dir. This patch makes uncommit to require the
config option `experimental.uncommitondirtydir` on a dirty PATH.
Original patch to evolve extension authored by Dan Villiom Podlaski Christiansen:
https://bitbucket.org/octobus/evolve-devel/pull-requests/8/bug-5977-uncommit-dirtiness/diff
Differential Revision: https://phab.mercurial-scm.org/D5940
Augie Fackler <augie@google.com> [Tue, 05 Mar 2019 09:51:57 -0500] rev 41863
cleanup: remove two bogus test names from python3 list
I suspect one of these was a typo from the start, the other appears to
have become a .t test at some point.
Differential Revision: https://phab.mercurial-scm.org/D6076
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 04 Mar 2019 15:46:54 +0100] rev 41862
revlog: preserve `_lazydelta` attribute in `revlog.clone`
The attribute was introduce in 688fc33e105d, Yuya Nishihara pointed out that
this preservation was missing. This changeset fixes the preservation and make
sure we set the attribute according the modes.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 04 Mar 2019 16:08:44 +0100] rev 41861
localrepo: explicit `_lock` arguments in `lock`
The argument for `_lock` are non-trivial, having them passed explicitly makes
thing clearer in my opinion. This is a Gratuitous change, I expect it will save
me (and others) time in the future.
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 03 Mar 2019 17:22:03 -0800] rev 41860
inno: remove w9xpopen.exe
w9xpopen.exe is a utility program shipped with Python <3.4
(https://bugs.python.org/issue14470 tracked its removal).
The program was used by subprocess to wrap invoked processes
on Windows 95 and 98 or when command.com was used in order to
work around a redirect bug.
The workaround is only used on ancient Windows versions -
versions that we shouldn't see in 2019.
While Python 2.7's subprocess module still references
w9xpopen.exe, not shipping it shouldn't matter unless we're
running an ancient version of Windows. Python will raise
an exception if w9xpopen.exe can't be found.
It's highly unlikely anyone is using current Mercurial releases
on these ancient Windows versions. So remove w9xpopen.exe
from the Inno installer.
.. bc::
The 32-bit Windows Inno installers no longer distribute
w9xpopen.exe. This should only impact people running
Mercurial on Windows 95, 98, or ME.
Differential Revision: https://phab.mercurial-scm.org/D6068
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 03 Mar 2019 15:53:27 -0800] rev 41859
inno: stop shipping pywin32
Ancient versions of Mercurial relied on pywin32 and I suspect
that's why we have this dependency.
We also ship the "keyring" package, which has a dependency
on "pywin32-ctypes" (providing the "win32ctypes" package).
This is a stripped down version of pywin32 that doesn't have
as many dependencies.
Since we don't have a dependency on pywin32 and since pywin32
is a bit annoying to package, let's get rid of it.
With this change, py2exe no longers picks up DLL dependencies
on various UCRT DLLs (because we no longer have a .pyd file
beloning to pywin32 which was pulling them in). So, we were
able to remove code in support of the UCRT DLLs.
.. bc::
The Windows Inno installers no longer ship the pywin32 package.
This package was being bundled for historical reasons. Mercurial
stopped using pywin32 several years ago and the disappearance
of this package should not have any meaningful impact.
Differential Revision: https://phab.mercurial-scm.org/D6067