Wed, 19 Jul 2017 13:17:49 -0700 tests: rename "u" to more usual "ui" in test-context.py
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
Wed, 03 Apr 2019 09:38:08 -0700 tests: better document the graft copy case
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
Wed, 03 Apr 2019 11:46:29 -0400 py2exe: add workaround to allow bundling of hgext3rd.* extensions
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
Tue, 02 Apr 2019 23:38:54 -0400 wix: fix the package build when not adding features
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
Mon, 01 Apr 2019 19:02:24 -0700 histedit: narrow the scope of discarded ui output
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
Fri, 29 Mar 2019 21:53:15 -0400 uncommit: abort if an explicitly given file cannot be uncommitted (BC)
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.
Mon, 25 Mar 2019 12:33:41 +0530 unshelve: disable unshelve during merge (issue5123)
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
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -7 +7 +10 +30 +100 +300 +1000 +3000 +10000 tip