Philippe Pepiot <philippe.pepiot@logilab.fr> [Thu, 04 Apr 2019 19:08:05 +0200] rev 42059
hgmanpage: use range instead of xrange
Philippe Pepiot <philippe.pepiot@logilab.fr> [Thu, 04 Apr 2019 19:06:48 +0200] rev 42058
packaging: allow to run make with python3
Use "?=", otherwise the variable cannot be set from environment.
Martin von Zweigbergk <martinvonz@google.com> [Wed, 03 Apr 2019 11:21:27 -0700] rev 42057
cleanup: use set literals where possible
Differential Revision: https://phab.mercurial-scm.org/D6192
Martin von Zweigbergk <martinvonz@google.com> [Wed, 19 Jul 2017 13:17:49 -0700] rev 42056
tests: rename "u" to more usual "ui" in test-context.py
Differential Revision: https://phab.mercurial-scm.org/D6191
Martin von Zweigbergk <martinvonz@google.com> [Wed, 03 Apr 2019 09:38:08 -0700] rev 42055
tests: better document the graft copy case
Differential Revision: https://phab.mercurial-scm.org/D6190
Augie Fackler <augie@google.com> [Wed, 03 Apr 2019 11:46:29 -0400] rev 42054
py2exe: add workaround to allow bundling of hgext3rd.* extensions
py2exe doesn't know how to handle namespace packages *at all*, so it treats
them like normal packages. As a result, if we try and bundle hgext3rd.evolve
in a py2exe build, it won't work if we install evolve into the virtualenv. In
order to work around this, tortoisehg installs hgext3rd.evolve etc into its
staged hg directory, since it doesn't use a virtualenv. As a workaround for us,
we'll just allow any extra packages users want bundled are part of hg during
the pseudo-install phase that py2exe uses. I'm not happy about this, but it
*works*.
As a sample of how you'd make an MSI with evolve bundled:
import os
import shutil
import subprocess
import tempfile
def stage_evolve(version):
"""Stage evolve for inclusion in py2exe binary."""
with tempfile.TemporaryDirectory() as temp:
evolve = os.path.join(temp, "evolve")
subprocess.check_call([
"hg.exe",
"clone",
"https://www.mercurial-scm.org/repo/evolve/",
"--update",
version,
evolve,
])
dest = os.path.join('..', 'hgext3rd', 'evolve')
if os.path.exists(dest):
shutil.rmtree(dest)
shutil.copytree(os.path.join(evolve, "hgext3rd", "evolve"), dest)
def main():
stage_evolve('tip')
print("\0")
print("hgext3rd")
print("hgext3rd.evolve")
print("hgext3rd.evolve.hack")
print("hgext3rd.evolve.thirdparty")
if __name__ == "__main__":
main()
is a script you can pass to the wix/build.py as --extra-packages-script,
and the resulting .msi will have an hg binary with evolve baked in. users
will still need to enable evolve in their hgrc, so you'd probably also
want to bundle configs in your msi for an enterprise environment, but that's
already easy to do with the support for extra features and wxs files in the
wix build process.
Differential Revision: https://phab.mercurial-scm.org/D6189
Augie Fackler <augie@google.com> [Tue, 02 Apr 2019 23:38:54 -0400] rev 42053
wix: fix the package build when not adding features
Should have used ifdef, not if. Sigh.
Differential Revision: https://phab.mercurial-scm.org/D6187
Rodrigo Damazio Bovendorp <rdamazio@google.com> [Mon, 01 Apr 2019 19:02:24 -0700] rev 42052
histedit: narrow the scope of discarded ui output
In
34165875fa5df813bec3a0cd348932b304d44efb, a lot of the output from
histedit was excluded. This slightly adjusts the scope of that exclusion,
to both discard more uninsteresting messages, and ensure that pre-merge-tool
output gets shown before the external merge tool is executed.
Differential Revision: https://phab.mercurial-scm.org/D6177
Matt Harbison <matt_harbison@yahoo.com> [Fri, 29 Mar 2019 21:53:15 -0400] rev 42051
uncommit: abort if an explicitly given file cannot be uncommitted (BC)
I've gotten burned several times by this in the last few days. The former tests
look simple enough, but if a good file and a bad file are given, the bad files
are silently ignored. Some commands like `forget` will warn about bogus files,
but that would likely get lost in the noise of an interactive uncommit. The
commit command aborts if a bad file is given, so this seems more consistent for
commands that alter the repository.
Navaneeth Suresh <navaneeths1998@gmail.com> [Mon, 25 Mar 2019 12:33:41 +0530] rev 42050
unshelve: disable unshelve during merge (
issue5123)
As stated in the
issue5123, unshelve can destroy the second parent of
the context when tried to unshelve with an uncommitted merge. This
patch makes unshelve to abort when called with an uncommitted merge.
See how shelve.mergefiles works. Commit structure looks like this:
```
... -> pctx -> tmpwctx -> shelvectx
/
/
second
merge parent
pctx = parent before merging working context(first merge parent)
tmpwctx = commited working directory after merge(with two parents)
shelvectx = shelved context
```
shelve.mergefiles first updates to pctx then it reverts shelvectx to pctx with:
```
cmdutil.revert(ui, repo, shelvectx, repo.dirstate.parents(),
*pathtofiles(repo, files),
**{'no_backup': True})
```
Reverting tmpwctx files that were merged from second parent to pctx makes them
added because they are not in pctx.
Changing this revert operation is crucial to restore parents after unshelve.
This is a complicated issue as this is not fixing a regression. Thus, for the
time being, unshelve during an uncommitted merge can be aborted.
(Details taken from http://mercurial.808500.n3.nabble.com/PATCH-V3-shelve-restore-parents-after-unshelve-
issue5123-tt4036858.html#
a4037408)
Differential Revision: https://phab.mercurial-scm.org/D6169