Augie Fackler <augie@google.com> [Fri, 12 Apr 2019 12:06:13 -0400] rev 42108
rebase: fix bug that prevented dry-run rebases from printing failures
As far as I can tell it should be fine to unconditionally skip
_prepareabortorcontinue if we're in the process of raising an Abort
here.
Differential Revision: https://phab.mercurial-scm.org/D6226
Augie Fackler <augie@google.com> [Fri, 12 Apr 2019 11:41:33 -0400] rev 42107
rebase: demonstrate bug in dry-run mode which causes cycles to not be reported
Differential Revision: https://phab.mercurial-scm.org/D6225
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 06 Apr 2019 17:48:11 +0200] rev 42106
test: minor cleanup to test-server-view.t
While looking into adding error output in this test, I did some cleanup.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 06 Apr 2019 10:44:22 +0200] rev 42105
repoview: improve documentation for `repo.filtered` method
I am sitting next to Joerg Sonnenberger and we are discussion his experience
with repoview. This first effect of this discussion is this documentation
clarification.
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Fri, 05 Apr 2019 14:30:52 -0400] rev 42104
revset: short docstring for checkstatus
This is where all the action happens for the status-related revsets,
and a little documentation doesn't hurt.
Georges Racinet <georges.racinet@octobus.net> [Thu, 11 Apr 2019 18:10:07 +0200] rev 42103
discovery: stop direct use of attribute of partialdiscovery
Instead of accessing `undecided` directly for ui display purposes,
we introduce a `stats()` method that could be extended in the future with
more interesting information.
This is in preparation for a forthcoming Rust version of this object.
Indeed, attributes and furthermore properties are a bit complicated for
classes in native code.
We could go further and rename `undecided` to mark it private, but `_undecided`
is already taken as support for `_undecided` lazyness.
Martin von Zweigbergk <martinvonz@google.com> [Wed, 10 Apr 2019 17:36:37 -0700] rev 42102
overlayworkingctx: remove misleading trailing slash from directory pattern
The paths passed into the matcher are normalized (this applies to
include patterns and regular patterns, and to both glob kind and path
kind), so the regex for input "foo/" ended up being "foo(?:/|$)".
Once we have a (recursive) pattern kind only for directories, we could
switch to that here and remove the "mfiles[0] == path" check. Until
then, let's at least make it not misleading.
Differential Revision: https://phab.mercurial-scm.org/D6224
Martin von Zweigbergk <martinvonz@google.com> [Wed, 10 Apr 2019 17:31:32 -0700] rev 42101
overlayworkingctx: fix file/dir audit to be repo-relative
Before this patch, test-rebase-inmemory.t would stop erroring out
about the conflict if you added a "cd a" before line 252. That was
because a glob matcher (which are relative) was unintentionally
used. That happened because the matcher was given "include" patterns
(not regular patterns), and "include" patterns are always glob by
default (i.e. unless you write them including the kind prefix). IOW,
the "default='path'" argument passed to ctx.match() was ignored.
Differential Revision: https://phab.mercurial-scm.org/D6223
Martin von Zweigbergk <martinvonz@google.com> [Wed, 10 Apr 2019 16:26:40 -0700] rev 42100
messages: replace some instances of "folder" by "directory"
I'm pretty sure this is our preferred term.
Differential Revision: https://phab.mercurial-scm.org/D6222
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 11 Apr 2019 18:34:56 +0200] rev 42099
match: fix re2 compability broken in 2e2699af5649
When using re2, we call test_match() instead of match() on the
compiled regex object. While match() returns a matcher object or None,
test_match() returns True or False. So since 2e2699af5649 running test
on a machine with a re2 install fails in many places. Instead we make
the code a bit more general and everything goes back to normal.
Pulkit Goyal <pulkit@yandex-team.ru> [Wed, 10 Apr 2019 03:10:53 +0530] rev 42098
py3: add b'' prefixes to new doctests in match.py
# skip-blame as just b'' prefixes
Differential Revision: https://phab.mercurial-scm.org/D6221
Pulkit Goyal <pulkit@yandex-team.ru> [Wed, 10 Apr 2019 03:02:31 +0530] rev 42097
py3: add one new passing test found by buildbot
Differential Revision: https://phab.mercurial-scm.org/D6220
Yuya Nishihara <yuya@tcha.org> [Tue, 09 Apr 2019 21:59:37 +0900] rev 42096
cext: cast s# arguments of Py_BuildValue() to Py_ssize_t
The doc doesn't state that "s#" of Py_BuildValue() is controlled by
PY_SSIZE_T_CLEAN (unlike the one for PyArg_ParseTuple()), but actually
it's switched to Py_ssize_t.
https://docs.python.org/2/c-api/arg.html#c.Py_BuildValue
https://github.com/python/cpython/blob/2.7/Python/modsupport.c#L432
Follow up for b01bbb8ff1f2 and 896b19d12c08.
Augie Fackler <augie@google.com> [Mon, 08 Apr 2019 10:52:04 -0400] rev 42095
remotefilelog: correctly reject wdir filenodes
This fixes `hg grep -r 'wdir()'` when remotefilelog is enabled and the working
directory contains uncommitted modifications.
Differential Revision: https://phab.mercurial-scm.org/D6217
Augie Fackler <augie@google.com> [Mon, 08 Apr 2019 10:56:55 -0400] rev 42094
remotefilelog: add tests of `hg grep -r 'wdir()'`
This demonstrates how remotefilelog breaks grepping dirtied working
directories. A future change will introduce a fix.
Differential Revision: https://phab.mercurial-scm.org/D6216
Martin von Zweigbergk <martinvonz@google.com> [Wed, 03 Apr 2019 16:03:41 -0700] rev 42093
config: read configs from directories in lexicographical order
Mercurial currently reads the .rc files specified in HGRCPATH (and the
system-default paths) in directory order, which is unspecified. My
team at work maintains a set of .rc files. So far there has been no
overlap between them, so we had not noticed this behavior. However, we
would now like to release some common .rc files and then have another
one per plaform with platform-specific overrides. It would be nice if
we can determine the load order by choosing names carefully. This
patch enables that by loading the .rc files in lexicographical order.
Before this patch, the added test case would consistently say "30" on
my file system (whatever I have -- some Linux FS).
Differential Revision: https://phab.mercurial-scm.org/D6193
Martin von Zweigbergk <martinvonz@google.com> [Wed, 03 Apr 2019 17:41:58 -0700] rev 42092
remotefilelog: fix crash on `hg addremove` of added-but-deleted file
If you `hg add` a file and then delete it from disk, and then run `hg
addremove`, the file ends up in the "removed" set that gets passed to
the findrenames() override. We then crash because the file is not in
the working copy parent. This patch fixes that.
Differential Revision: https://phab.mercurial-scm.org/D6194
Matt Harbison <matt_harbison@yahoo.com> [Fri, 05 Apr 2019 23:07:11 -0400] rev 42091
packaging: ensure that --python is an absolute path when building on Windows
For whatever reason, even though only python2 is on PATH, passing `python.exe`
causes the later check that it's not py3 to bail out.
Matt Harbison <matt_harbison@yahoo.com> [Fri, 05 Apr 2019 22:47:45 -0400] rev 42090
packaging: don't crash building wix with python3.6 and earlier
`capture_output` was added in 3.7. I was tempted to just check and abort in
build.py, since Windows doesn't have the Linux problem where some distros only
ship an older python. But this is in a library that could be used elsewhere in
the future.
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Wed, 03 Apr 2019 23:55:03 -0400] rev 42089
chistedit: add basic colours to diff view
This isn't complete, and it would be nice to show the exact same
colours that `hg diff` would show. That goal is too lofty, so this
just shows some basic colours, on the premise that a little is better
than nothing.
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Fri, 05 Apr 2019 14:54:45 -0400] rev 42088
chistedit: use default curses colours
Terminals will define default colours (for example, white text on
black background), but curses doesn't obey those default colours
unless told to do so.
Calling `curses.use_default_colors` makes curses obey the default
terminal colours. One of the most obvious effects is that this allows
transparency on terminals that support it.
This also brings chistedit closer in appearance to crecord, which also
uses default colours.
The call may error out if the terminal doesn't support colors, but as
far as I can tell, everything still works. If we need a more careful
handling of lack of colours, blame me for not doing it now.
Denis Laxalde <denis@laxalde.org> [Sun, 07 Apr 2019 16:53:47 +0200] rev 42087
match: let regex match function return a boolean
Match function for regex pattern kind is built through
_buildregexmatch() and _buildmatch() using _rematcher() that returns a
re.match function, which either returns a match object or None. This
does not conform to Mercurial's matcher interface for __call__() or
exact(), which are expected to return a boolean value. We fix this by
building a lambda around _rematcher() in _buildregexmatch().
Accordingly, we update doctest examples to remove bool() calls that are
now useless.
Denis Laxalde <denis@laxalde.org> [Sun, 07 Apr 2019 17:16:58 +0200] rev 42086
match: make arguments of _expandsets() optional
Arguments 'ctx', 'listsubrepos' and 'badfn' are optional in function
body.
Denis Laxalde <denis@laxalde.org> [Sun, 07 Apr 2019 17:14:29 +0200] rev 42085
match: make _donormalize's auditor and warn arguments optional
Argument 'warn' is actually non-required, since there's a 'if warn:'
check before usage. Argument 'auditor' is passed to
pathutil.canonpath(), in which it is optional.
Denis Laxalde <denis@laxalde.org> [Mon, 08 Apr 2019 09:34:50 +0200] rev 42084
match: add doctest examples in match()
Make the docstring raw, as it now includes escape characters.
Denis Laxalde <denis@laxalde.org> [Sat, 06 Apr 2019 18:20:49 +0200] rev 42083
match: complete documentation of match() parameters
Denis Laxalde <denis@laxalde.org> [Sat, 06 Apr 2019 17:54:13 +0200] rev 42082
match: add doctest examples for patkind()
Denis Laxalde <denis@laxalde.org> [Sat, 06 Apr 2019 15:21:55 +0200] rev 42081
match: add a docstring with doctest examples to patternmatcher
Doctest examples aim at illustrating how __call__() and exact() are
different, depending on the pattern kind.
Denis Laxalde <denis@laxalde.org> [Sun, 07 Apr 2019 12:21:23 +0200] rev 42080
match: add doctest examples for exactmatcher
Make the docstring raw, since it now includes escape characters.
Martin von Zweigbergk <martinvonz@google.com> [Fri, 05 Apr 2019 11:24:00 -0700] rev 42079
localrepo: don't allow lookup of working directory revision
It seems that repo.lookup(), which is what supports the "lookup" wire
protocol command, should not allow the working copy revision
input.
This fixes both the pull test and the convert test I just added.
Differential Revision: https://phab.mercurial-scm.org/D6215
Martin von Zweigbergk <martinvonz@google.com> [Fri, 05 Apr 2019 11:22:26 -0700] rev 42078
tests: demonstrate broken pull of "ffffffffffff" revision
Differential Revision: https://phab.mercurial-scm.org/D6214
Martin von Zweigbergk <martinvonz@google.com> [Fri, 05 Apr 2019 11:12:08 -0700] rev 42077
tests: demonstrate broken `hg convert` if "ffffffffffff" is in description
Differential Revision: https://phab.mercurial-scm.org/D6213
Martin von Zweigbergk <martinvonz@google.com> [Fri, 05 Apr 2019 11:08:17 -0700] rev 42076
tests: add test of for hash reference translation by `hg convert`
The convert extension translates commit references in the commit
message. We didn't have any explicit testing of this before, so let's
add a test.
Differential Revision: https://phab.mercurial-scm.org/D6212
Matt Harbison <matt_harbison@yahoo.com> [Fri, 05 Apr 2019 18:36:43 -0400] rev 42075
py3: write out hgextindex as bytes in setup.py
I hit this trying to build the py2exe target using python3, just to see what
would happen. After commenting out `py2exe.Distribution` in setup.py and
pointing to a local copy of py2exe that supports python3[1], it complained that
`out` was bytes, not str.
[1] https://github.com/albertosottile/py2exe/releases/tag/v0.9.3.0
Philippe Pepiot <philippe.pepiot@logilab.fr> [Thu, 04 Apr 2019 15:40:48 +0200] rev 42074
setup: fix a possible NameError on rust build
File "setup.py", line 975, in rustbuild
"command: %r, environment: %r" % (self.rustsrcdir, cmd, env))
NameError: global name 'cmd' is not defined
Arun Chandrasekaran <aruncxy@gmail.com> [Mon, 01 Apr 2019 22:11:54 -0700] rev 42073
crecord: new keys g & G to navigate to the top and bottom respectively
This patch introduces two new keys 'g' and 'G' that helps to navigate to the
top and bottom of the file/hunk/line respectively. This is inline with the shortcuts
used in man, less, more and such tools that makes it convenient to navigate
swiftly.
'g' or HOME navigates to the top most file in the ncurses window.
'G' or END navigates to the bottom most file/hunk/line depending on the whether
the fold is active or not.
If the bottom most file is folded, it navigates to that file and stops there.
If the bottom most file is unfolded, it navigates to the bottom most hunk in
that file and stops there. If the bottom most hunk is unfolded, it navigates to
the bottom most line in that hunk.
Differential Revision: https://phab.mercurial-scm.org/D6178
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Thu, 04 Apr 2019 10:41:55 -0400] rev 42072
chistedit: properly show verbose diffs
I'm not sure if that ever worked and it's an internal API breakage,
but `"verbose": True` is not correctly parsed, as most of these
options are parsed by diffopts, whereas verbose is a global option.
Setting the UI to verbose instead does work and does show a verbose
patch, with full commit message.
It also shows all files, which unfortunately are a bit hard to read on
a single line in the default verbose template. Thus, we also change
the default template to use the status template, which shows one file
per line as well as its modification state.
Denis Laxalde <denis.laxalde@logilab.fr> [Thu, 04 Apr 2019 11:35:18 +0200] rev 42071
interactive: do not prompt about files given in command line
For commit and revert commands with --interactive and explicit files
given in the command line, we now skip the invite to "examine changes to
<file> ? [Ynesfdaq?]". The reason for this is that, if <file> is
specified by the user, asking for confirmation is redundant.
In patch.filterpatch(), we now use an optional "match" argument to
conditionally call the prompt() function when entering a new "header"
item. We use .exact() method to compare with files from the "header" in
order to only consider (rel)path patterns.
Add tests with glob patterns for commit and revert, to make sure we
still ask to examine files in these cases.
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 04 Apr 2019 17:34:43 -0700] rev 42070
zstandard: vendor python-zstandard 0.11
The upstream source distribution from PyPI was extracted. Unwanted
files were removed.
The clang-format ignore list was updated to reflect the new source
of files.
The project contains a vendored copy of zstandard 1.3.8. The old
version was 1.3.6. This should result in some minor performance wins.
test-check-py3-compat.t was updated to reflect now-passing tests on
Python 3.8.
Some HTTP tests were updated to reflect new zstd compression output.
# no-check-commit because 3rd party code has different style guidelines
Differential Revision: https://phab.mercurial-scm.org/D6199
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 04 Apr 2019 15:24:03 -0700] rev 42069
cext: make osutil.c PY_SSIZE_T_CLEAN
This is needed to avoid a deprecation warning on Python 3.8.
With this change, we no longer see deprecation warnings for
this issue on Python 3.8.
Differential Revision: https://phab.mercurial-scm.org/D6198
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 04 Apr 2019 15:21:30 -0700] rev 42068
cext: make parsers.c PY_SSIZE_T_CLEAN
This is needed to avoid a deprecation warning in Python 3.8. I believe
the conversion of int to Py_ssize_t is harmless in the changed
locations. But this being C code, it should be audited with care.
Differential Revision: https://phab.mercurial-scm.org/D6197
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 04 Apr 2019 15:18:06 -0700] rev 42067
cext: make revlog.c PY_SSIZE_T_CLEAN
Without this, Python 3.8 emits a deprecation warning, as using
int for # values is deprecated. Many existing modules use
PY_SSIZE_T_CLEAN, so this shouldn't be contentious.
I audited the file for all # formatters and verified we are
using Py_ssize_t everywhere now.
Differential Revision: https://phab.mercurial-scm.org/D6196
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 04 Apr 2019 18:20:36 -0700] rev 42066
tests: add optional output for Python 2.7 deprecation
We already had one of these a few lines above. We need it here as
well.
Differential Revision: https://phab.mercurial-scm.org/D6203
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 04 Apr 2019 18:01:48 -0700] rev 42065
setup: use raw string for regular expression
Otherwise Python 3.8 complains about the backslash.
Differential Revision: https://phab.mercurial-scm.org/D6202
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 04 Apr 2019 18:01:02 -0700] rev 42064
automation: use raw strings when there are backslashes
Otherwise Python 3.8 complains.
Differential Revision: https://phab.mercurial-scm.org/D6201
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 04 Apr 2019 17:47:25 -0700] rev 42063
perf: make perf.run-limits code work with Python 3
We need b'' because perf.py isn't run through the source
transformer.
We need to cast the exception to bytes using pycompat.bytestr()
because ValueError can't be %s formatted due to built-in exceptions
lacking __bytes__.
We need to pycompat.sysstr() before the float() and int() cast
so the ValueError message doesn't have b'' in it.
Even with that, it looks like the error message for the ValueError
for float casts added quotes, so we need to account for that in test
output.
Differential Revision: https://phab.mercurial-scm.org/D6200
Martin von Zweigbergk <martinvonz@google.com> [Mon, 25 Dec 2017 05:55:50 -0800] rev 42062
localrepo: rename crev in _filecommit() to cnode, since it's a node
I know we often use "rev" generically, but here's it always a node, so
it helps to be specific.
Differential Revision: https://phab.mercurial-scm.org/D6181
Jerry Montfort <jerry.montfort@fake-box.com> [Fri, 05 Apr 2019 04:09:41 +0530] rev 42061
tests: unset environment variable P in test-revset2.t (issue6109)
The test tests/test-revset2.t fails the test case
"Test repo.anyrevs with customized revset overrides" (line 1609)
if the environment variable P is set. The test implicitly expects that the
environment, in which it is started, does not export the variable 'P'.
To solve this issue, unset 'P' right before the test commands are run.
Differential Revision: https://phab.mercurial-scm.org/D6195
Philippe Pepiot <philippe.pepiot@logilab.fr> [Thu, 04 Apr 2019 19:08:37 +0200] rev 42060
hgmanpage: use a py2 and py3 compatible iterable protocol
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
Augie Fackler <raf@durin42.com> [Mon, 01 Apr 2019 20:01:48 -0400] rev 42049
wix: add functionality to inject additional Features into installer
This is the last bit required to be able to glue extra configs etc into
the installer.
Differential Revision: https://phab.mercurial-scm.org/D6180
Augie Fackler <raf@durin42.com> [Mon, 01 Apr 2019 16:21:47 -0400] rev 42048
wix: add support for additional wxs files
As with my previous change for an --extra-prebuiild-script, I'm
assuming this is predominantly useful in an enterprise environment
and am only adding this to wix and not also to inno install scripts.
Differential Revision: https://phab.mercurial-scm.org/D6179
Augie Fackler <augie@google.com> [Wed, 20 Mar 2019 13:18:37 -0400] rev 42047
wix: add a hook for a prebuild script to inject extra libraries
I need this to build packages for Google so we can bundle some
extensions in the installed image. My assumption is that this is most
interesting for the .msi images so I only wired it up there. I'm not
thrilled with the interface this provides, but it was an easy way to
retain debug messages on Windows while also having enough structure to
know what lines are actually module names for py2exe.
Still pending on my end: I need to bundle a couple of config files,
and at least one data file. I'm open to advice on how to do those
things, and how to do this better.
Differential Revision: https://phab.mercurial-scm.org/D6164
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 27 Mar 2019 18:26:54 +0100] rev 42046
compression: introduce an official `format.revlog-compression` option
This option supersedes the `experiment.format.compression` option. The value
currently supported are zlib (default) and zstd (if Mercurial was compiled with
zstd support).
The option gained an explicit reference to `revlog` since this is the target
usage here. Different storage methods might require different compression
strategies.
In our tests, using zstd give a significant CPU usage improvement (both
compression and decompressing) while keeping similar repository size.
Zstd as other interresting mode (dictionnary, pre-text, etc…) that are probably
worth exploring. However, just plain switching from zlib to zstd provide a large
benefit.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 02 Apr 2019 11:03:46 -0700] rev 42045
compression: display compression level in debugformat
Now that we have options to control the compression level, we teach `hg
debugformat` about them. This is a useful information when comparing
repositories.
Note that we have no trace of the compression level used to store existing
deltas. Actually, it would even varies from one delta to another. So we display
the currently set value.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 27 Mar 2019 18:35:59 +0100] rev 42044
compression: introduce a `storage.revlog.zstd.level` configuration
This option control the zstd compression level used when compressing revlog
chunk. The usage of zstd for revlog compression has not graduated from
experimental yet, but we intend to fix that soon.
The option name for the compression level is more straight forward to pick, so
this changesets comes first. Having a dedicated option for each compression
engine is useful because they don't support the same range of values.
I ran the same measurement as for the zlib compression level (in the parent
changesets). The variation in repository size is stay mostly in the same (small)
range. The "read/write" performance see smallish variation, but are overall much
better than zlib. Write performance show the same tend of having better write
performance for when reaching high-end compression.
Again, we don't intend to change the default zstd compression level (currently:
3) in this series. However this is worth investigating in the future.
The Performance comparison of zlib vs zstd is quite impressive. The repository
size stay in the same range, but the performance are much better in all
situations.
Comparison summary
==================
We are looking at:
- performance range for zlib
- performance range for zstd
- comparison of default zstd (level-3) to default zlib (level 6)
- comparison of the slowest zstd time to the fastest zlib time
Read performance:
-----------------
| zlib | zstd | cmp | f2s
mercurial | 0.170159 - 0.189219 | 0.144127 - 0.149624 | 80% | 88%
pypy | 2.679217 - 2.768691 | 1.532317 - 1.705044 | 60% | 63%
netbeans | 122.477027 - 141.620281 | 72.996346 - 89.731560 | 58% | 73%
mozilla | 147.867662 - 170.572118 | 91.700995 - 105.853099 | 56% | 71%
Write performance:
------------------
| zlib | zstd | cmp | f2s
mercurial | 53.250304 - 56.2936129 | 40.877025 - 45.677286 | 75% | 86%
pypy | 460.721984 - 476.589918 | 270.545409 - 301.002219 | 63% | 65%
netbeans | 520.560316 - 715.930400 | 370.356311 - 428.329652 | 55% | 82%
mozilla | 739.803002 - 987.056093 | 505.152906 - 591.930683 | 57% | 80%
Raw data
--------
repo alg lvl .hg/store size 00manifest.d read write
mercurial zlib 1 49,402,813 5,963,475 0.170159 53.250304
mercurial zlib 6 47,197,397 5,875,730 0.182820 56.264320
mercurial zlib 9 47,121,596 5,849,781 0.189219 56.293612
mercurial zstd 1 49,737,084 5,966,355 0.144127 40.877025
mercurial zstd 3 48,961,867 5,895,208 0.146376 42.268142
mercurial zstd 5 48,200,592 5,938,676 0.149624 43.162875
mercurial zstd 10 47,833,520 5,913,353 0.145185 44.012489
mercurial zstd 15 47,314,604 5,728,679 0.147686 45.677286
mercurial zstd 20 47,330,502 5,830,539 0.145789 45.025407
mercurial zstd 22 47,330,076 5,830,539 0.143996 44.690460
pypy zlib 1 370,830,572 28,462,425 2.679217 460.721984
pypy zlib 6 340,112,317 27,648,747 2.768691 467.537158
pypy zlib 9 338,360,736 27,639,003 2.763495 476.589918
pypy zstd 1 362,377,479 27,916,214 1.532317 270.545409
pypy zstd 3 354,137,693 27,905,988 1.686718 294.951509
pypy zstd 5 342,640,043 27,655,774 1.705044 301.002219
pypy zstd 10 334,224,327 27,164,493 1.567287 285.186239
pypy zstd 15 329,000,363 26,645,965 1.637729 299.561332
pypy zstd 20 324,534,039 26,199,547 1.526813 302.149827
pypy zstd 22 324,530,595 26,198,932 1.525718 307.821218
netbeans zlib 1 1,281,847,810 165,495,457 122.477027 520.560316
netbeans zlib 6 1,205,284,353 159,161,207 139.876147 715.930400
netbeans zlib 9 1,197,135,671 155,034,586 141.620281 678.297064
netbeans zstd 1 1,259,581,737 160,840,613 72.996346 370.356311
netbeans zstd 3 1,232,978,122 157,691,551 81.622317 396.733087
netbeans zstd 5 1,208,034,075 160,246,880 83.080549 364.342626
netbeans zstd 10 1,188,624,176 156,083,417 79.323935 403.594602
netbeans zstd 15 1,176,973,589 153,859,477 89.731560 428.329652
netbeans zstd 20 1,162,958,258 151,147,535 82.842667 392.335349
netbeans zstd 22 1,162,707,029 151,150,220 82.565695 402.840655
mozilla zlib 1 2,775,497,186 298,527,987 147.867662 751.263721
mozilla zlib 6 2,596,856,420 286,597,671 170.572118 987.056093
mozilla zlib 9 2,587,542,494 287,018,264 163.622338 739.803002
mozilla zstd 1 2,723,159,348 286,617,532 91.700995 570.042751
mozilla zstd 3 2,665,055,001 286,152,013 95.240155 561.412805
mozilla zstd 5 2,607,819,817 288,060,030 101.978048 505.152906
mozilla zstd 10 2,558,761,085 283,967,648 104.113481 497.771202
mozilla zstd 15 2,526,216,060 275,581,300 105.853099 591.930683
mozilla zstd 20 2,485,114,806 266,478,859 95.268795 576.515389
mozilla zstd 22 2,484,869,080 266,456,505 94.429282 572.785537
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 27 Mar 2019 18:35:27 +0100] rev 42043
compression: introduce a `storage.revlog.zlib.level` configuration
This option control the zlib compression level used when compression revlog
chunk.
This is also a good excuse to pave the way for a similar configuration option
for the zstd compression engine. Having a dedicated option for each compression
algorithm is useful because they don't support the same range of values.
Using a higher zlib compression impact CPU consumption at compression time, but
does not directly affected decompression time. However dealing with small
compressed chunk can directly help decompression and indirectly help other
revlog logic.
I ran some basic test on repositories using different level. I am using the
mercurial, pypy, netbeans and mozilla-central clone from our benchmark suite.
All tested repository use sparse-revlog and got all their delta recomputed.
The different compression level has a small effect on the repository size
(about 10% variation in the total range). My quick analysis is that revlog
mostly store small delta, that are not affected by the compression level much.
So the variation probably mostly comes from better compression of the snapshots
revisions, and snapshot revision only represent a small portion of the
repository content.
I also made some basic timings measurements. The "read" timings are gathered using
simple run of `hg perfrevlogrevisions`, the "write" timings using `hg
perfrevlogwrite` (restricted to the last 5000 revisions for netbeans and
mozilla central). The timings are gathered on a generic machine, (not one of
our performance locked machine), so small variation might not be meaningful.
However large trend remains relevant.
Keep in mind that these numbers are not pure compression/decompression time.
They also involve the full revlog logic. In particular the difference in chunk
size has an impact on the delta chain structure, affecting performance when
writing or reading them.
On read/write performance, the compression level has a bigger impact.
Counter-intuitively, the higher compression levels improve "write" performance
for the large repositories in our tested setting. Maybe because the last 5000
delta chain end up having a very different shape in this specific spot? Or maybe
because of a more general trend of better delta chains thanks to the smaller
chunk and snapshot.
This series does not intend to change the default compression level. However,
these result call for a deeper analysis of this performance difference in the
future.
Full data
=========
repo level .hg/store size 00manifest.d read write
----------------------------------------------------------------
mercurial 1 49,402,813 5,963,475 0.170159 53.250304
mercurial 6 47,197,397 5,875,730 0.182820 56.264320
mercurial 9 47,121,596 5,849,781 0.189219 56.293612
pypy 1 370,830,572 28,462,425 2.679217 460.721984
pypy 6 340,112,317 27,648,747 2.768691 467.537158
pypy 9 338,360,736 27,639,003 2.763495 476.589918
netbeans 1 1,281,847,810 165,495,457 122.477027 520.560316
netbeans 6 1,205,284,353 159,161,207 139.876147 715.930400
netbeans 9 1,197,135,671 155,034,586 141.620281 678.297064
mozilla 1 2,775,497,186 298,527,987 147.867662 751.263721
mozilla 6 2,596,856,420 286,597,671 170.572118 987.056093
mozilla 9 2,587,542,494 287,018,264 163.622338 739.803002
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 27 Mar 2019 19:34:10 +0100] rev 42042
compression: accept level management for zlib compression
We update the zlib related class to be support setting the compression level.
This changeset focus on updating the internal only. A way to configure this
level will be introduced in the next changeset.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 27 Mar 2019 16:45:14 +0100] rev 42041
util: extract compression code in `mercurial.utils.compression`
The code seems large enough to be worth extracting. This is similar to what was
done for various module in `mercurial/utils/`.
Since None of the compression logic takes a `ui` objet, issuing deprecation
warning is tricky. Luckly the logic does not seems to have many external users.
Martin von Zweigbergk <martinvonz@google.com> [Sat, 30 Mar 2019 13:13:10 -0700] rev 42040
merge: make "labels" argument to graft() optional, like it is for update()
graft() just passes the argument on to update(), and update() doesn't
require it, so graft() shouldn't either.
Differential Revision: https://phab.mercurial-scm.org/D6175
Martin von Zweigbergk <martinvonz@google.com> [Sun, 31 Mar 2019 09:39:02 -0700] rev 42039
revset: remove comment about linkrev workaround from user-facing docs
I think the code is clear enough so we don't need to keep the comment
at all (by now, most Mercurial developers are probably familiar with
the linkrevs issues).
Differential Revision: https://phab.mercurial-scm.org/D6176
Martin von Zweigbergk <martinvonz@google.com> [Fri, 29 Mar 2019 11:32:02 -0700] rev 42038
shelve: let cmdutil.revert() take care of backing up untracked files
cmdutil.revert() backs up untracked files, so I don't see a reason to
do it shelve.mergefiles(). We have tests for this and they still pass.
Differential Revision: https://phab.mercurial-scm.org/D6174
Martin von Zweigbergk <martinvonz@google.com> [Fri, 29 Mar 2019 11:31:42 -0700] rev 42037
shelve: stop passing list of files to revert
It seems to work just fine to not specify any files here. I suspect it
looked the way it did for historical reasons. It apparently used to
use merge instead of rebase until 1d7a36ff2615 (shelve: use rebase
instead of merge (issue4068), 2013-10-23) and it makes sense to want
to restrict the set of files then.
I noticed this because of the files.extend(shelvectx.p1().files()). If
the working copy was clean before, then shelvectx.p1() will be the
working copy parent and that ended up adding all the files in that
set. In our Google-internal Mercurial setup (including a FUSE) that
was very noticeably slow when the working copy parent happened to have
many files in large directories.
This patch doesn't yet remove the call to shelvectx.p1().files(). We
also use that set for deciding what to back up. I'm pretty sure it's
safe to back up only the set of files we already back even if we no
longer restrict the set of files to revert, so this patch should be
safe on its own. Regardless, the next patch will delegate the
backing-up to cmdutil.revert().
Incidentally, this also gets rid of a repo.pathto() that I had earlier
wanted to get rid of.
Differential Revision: https://phab.mercurial-scm.org/D6173
Martin von Zweigbergk <martinvonz@google.com> [Wed, 27 Mar 2019 14:55:46 -0700] rev 42036
remotefilelog: prefetch files in deterministic order
I have been troubleshooting some slowness in this area (it's unclear
if it's the client or server that's to blame, but that's beside the
point) and it's a lot easier to do troubleshoot if the files are
prefetched in the same order each time.
Differential Revision: https://phab.mercurial-scm.org/D6172
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 26 Mar 2019 17:35:28 +0100] rev 42035
debugdiscovery: display time elapsed during the discovery step
This is a useful information. Now that we perform more analysing after the
discovery is done, it is worth have a more precise measurement. For serious
timing analysis use `hg perfdiscovery`.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 26 Mar 2019 17:26:54 +0100] rev 42034
debugdiscovery: only list common heads on verbose
The list of common heads is only part of the useful information. In addition on
repository with many heads, the information is very not helpful (just fill a
couple of screen with hash). As a result we hide it behind a --verbose flag.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 26 Mar 2019 17:26:11 +0100] rev 42033
debugdiscovery: drop duplicated information
The old line informing about the local being a superset or subset of the remote
is redundant with the newly introduced data. So we drop it.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 26 Mar 2019 17:25:22 +0100] rev 42032
debugdiscovery: display more statistic about the common set
We display a lot more information now. Especially, we display the overlap
between the common heads and the local/remote heads. There are various
optimization geared toward heads, as a result, the less common the heads the
more complex the discovery. Having this information easily accessible help when
working on discovery.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 26 Mar 2019 14:04:33 +0100] rev 42031
debugdiscovery: small internal refactoring
The part of the code displaying statistic is made independant from the one
running the discovery. In the same do, the declaration of the discovery
function is a bit simplified.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 26 Mar 2019 14:02:40 +0100] rev 42030
debugdiscovery: allow to select random seed during debugdiscovery run
The randomness can lead to large timing difference, controling it is important.
Pulkit Goyal <pulkit@yandex-team.ru> [Sun, 17 Mar 2019 18:45:53 +0300] rev 42029
discovery: move cl.hasnode outside of the for-loop
IIUC, resolving attributes for changelog can lead to some overhead. So this
patch moves that to outside of a for-loop.
Differential Revision: https://phab.mercurial-scm.org/D6147
Pulkit Goyal <pulkit@yandex-team.ru> [Sun, 17 Mar 2019 18:43:27 +0300] rev 42028
discovery: prevent deleting items from a dictionary
Removing elements from Python dictionary is expensive. So let's prevent adding
them instead.
I added a newline to make code look a bit better.
Differential Revision: https://phab.mercurial-scm.org/D6146
Pulkit Goyal <pulkit@yandex-team.ru> [Sun, 17 Mar 2019 18:34:28 +0300] rev 42027
discovery: drop some unused sets
Differential Revision: https://phab.mercurial-scm.org/D6145
Pulkit Goyal <pulkit@yandex-team.ru> [Sun, 17 Mar 2019 18:29:23 +0300] rev 42026
discovery: prevent recomputing info about server and outgoing changesets
We already iterate over the outgoing.missing above and lookup repo for them. So
let's reuse info calculated at that time instead of recomputing that again.
Also we calculate the set of remotebranches by doing set(remotemap), so let's
reuse that again.
Upcoming patches will clean things a bit more.
Differential Revision: https://phab.mercurial-scm.org/D6144
Alexander Kobjolke <alex@jakalx.net> [Thu, 21 Mar 2019 21:44:29 +0100] rev 42025
crecord: draw on the whole screen
When starting crecord, one can see that it has a small gap on the rightmost
column which doesn't get used. This is in contrast to other interactive curses
frontends such as chistedit.
Disabling the displaying of the cursor allows drawing on the whole availabe
area and thus some hacky code in align() could be removed.
Differential Revision: https://phab.mercurial-scm.org/D6171
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 15 Mar 2019 11:24:08 -0700] rev 42024
automation: perform tasks on remote machines
Sometimes you don't have access to a machine in order to
do something. For example, you may not have access to a Windows
machine required to build Windows binaries or run tests on that
platform.
This commit introduces a pile of code intended to help
"automate" common tasks, like building release artifacts.
In its current form, the automation code provides functionality
for performing tasks on Windows EC2 instances.
The hgautomation.aws module provides functionality for integrating
with AWS. It manages EC2 resources such as IAM roles, EC2
security groups, AMIs, and instances.
The hgautomation.windows module provides a higher-level
interface for performing tasks on remote Windows machines.
The hgautomation.cli module provides a command-line interface to
these higher-level primitives.
I attempted to structure Windows remote machine interaction
around Windows Remoting / PowerShell. This is kinda/sorta like
SSH + shell, but for Windows. In theory, most of the functionality
is cloud provider agnostic, as we should be able to use any
established WinRM connection to interact with a remote. In
reality, we're tightly coupled to AWS at the moment because
I didn't want to prematurely add abstractions for a 2nd cloud
provider. (1 was hard enough to implement.)
In the aws module is code for creating an image with a fully
functional Mercurial development environment. It contains VC9,
VC2017, msys, and other dependencies. The image is fully capable
of building all the existing Mercurial release artifacts and
running tests.
There are a few things that don't work. For example, running
Windows tests with Python 3. But building the Windows release
artifacts does work. And that was an impetus for this work.
(Although we don't yet support code signing.)
Getting this functionality to work was extremely time consuming.
It took hours debugging permissions failures and other wonky
behavior due to PowerShell Remoting. (The permissions model for
PowerShell is crazy and you brush up against all kinds of
issues because of the user/privileges of the user running
the PowerShell and the permissions of the PowerShell session
itself.)
The functionality around AWS resource management could use some
improving. In theory we support shared tenancy via resource
name prefixing. In reality, we don't offer a way to configure
this.
Speaking of AWS resource management, I thought about using a tool
like Terraform to manage resources. But at our scale, writing a
few dozen lines of code to manage resources seemed acceptable.
Maybe we should reconsider this if things grow out of control.
Time will tell.
Currently, emphasis is placed on Windows. But I only started
there because it was likely to be the most difficult to implement.
It should be relatively trivial to automate tasks on remote Linux
machines. In fact, I have a ~1 year old script to run tests on a
remote EC2 instance. I will likely be porting that to this new
"framework" in the near future.
# no-check-commit because foo_bar functions
Differential Revision: https://phab.mercurial-scm.org/D6142
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 09 Mar 2019 16:36:08 -0800] rev 42023
contrib: PowerShell script to install development dependencies
Configuring a Windows machine to hack on Mercurial is a bit of work
and it isn't documented very well.
This commit introduces a PowerShell script to automate going from
a fresh Windows install to an environment suitable for building
Mercurial, its installers, and running tests.
Differential Revision: https://phab.mercurial-scm.org/D6141
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Tue, 26 Mar 2019 11:53:30 -0400] rev 42022
chistedit: change in-progress message
Saying "running histedit" is an artifact of when chistedit was a
separate thing from histedit. I found the message a bit confusing,
since wasn't I running histedit from the beginning, just from the
curses interface?
The whole thing is now histedit, both the curses interface and the
underlying procedure to apply a plan, so let's use a message that
doesn't make a distinction.
Augie Fackler <augie@google.com> [Tue, 26 Mar 2019 10:21:17 -0400] rev 42021
perf: copyedit a few documentation strings
Differential Revision: https://phab.mercurial-scm.org/D6170
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Sun, 24 Mar 2019 20:13:13 -0400] rev 42020
shelve: add --keep to list of allowables
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 17 Mar 2019 12:30:52 +0000] rev 42019
perf: introduce a `perf.run-limits` options
This options make it possible to configure the number of run that the extensions
will perform. This is useful for automated benchmark or for performance
measurement that need better accuracy.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 16 Mar 2019 19:11:19 +0000] rev 42018
perf: pass limits as a function argument
The function applying the limit has no access to the configuration. Therefore,
some higher layer will have to pass it as argument.
We do this in an independent change to clarify the next change.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 16 Mar 2019 19:08:27 +0000] rev 42017
perf: more flexible implementation for checking stop conditions
We want to make this logic simpler to configure. The first step is to stop
hard-coding every values.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 25 Mar 2019 08:41:02 -0700] rev 42016
perf: document perfparents
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 25 Mar 2019 13:43:40 +0100] rev 42015
perf: document config options
We have configuration, so we better document it.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 25 Mar 2019 13:16:53 +0100] rev 42014
tests: use "perf" as a the extension name in test-contrib-perf.t
This is simpler and seems more "inline" with the name people usually use for
this extensions.
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Fri, 22 Mar 2019 11:26:47 -0400] rev 42013
shelve: do not update when keeping changes, just move the dirstate
This is to leave the working directory unchanged. We reuse the match
object as an optimisation.
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Fri, 22 Mar 2019 13:03:26 -0400] rev 42012
shelve: refactor _shelvecreatedcommit's match object into calling site
We might need to use this match object again to move the dirstate in
case the user requested to `--keep` the changes.
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Fri, 22 Mar 2019 11:24:23 -0400] rev 42011
shelve: new keep option
Does nothing yet. The docstring describes what it will soon be doing.
Matt Harbison <matt_harbison@yahoo.com> [Thu, 21 Mar 2019 21:40:22 -0400] rev 42010
diff: support diffing explicit files in subrepos
Most other commands support implied recursion based on file names already.
Danny Hooper <hooper@google.com> [Thu, 21 Mar 2019 18:27:09 -0700] rev 42009
fix: make the order of the work queue deterministic
This makes any output generated during the parallel phase of execution stable
if parallelism is disabled. This helps write tests like that in the future.
Differential Revision: https://phab.mercurial-scm.org/D6166
Danny Hooper <hooper@google.com> [Thu, 21 Mar 2019 18:35:39 -0700] rev 42008
fix: allow fixing untracked files when given as arguments
It's more useful to fix the file than to silently avoid it when the user does
this:
hg fix --working-dir untracked-file
We will still do nothing to ignored files, even if they are specified. This may
be safer, given that such files can unexpectedly slip into the arguments via a
shell glob or fileset.
Differential Revision: https://phab.mercurial-scm.org/D6165
Pulkit Goyal <pulkit@yandex-team.ru> [Tue, 19 Mar 2019 16:26:52 +0300] rev 42007
branchcache: have a hasnode function to validate nodes
Upcoming patches will delay node validation until it's required. So we need to a
way in branchcache class to check whether a node exists or node.
Other options were making repo or changelog an attribute of branchcache object.
But the branchcache depends on filters so I decided to pass a function object.
Differential Revision: https://phab.mercurial-scm.org/D6157
Pulkit Goyal <pulkit@yandex-team.ru> [Tue, 19 Mar 2019 16:20:02 +0300] rev 42006
branchcache: add attributes to track which nodes are verified
Half of the cost of loading branchcache comes from verifiying all the nodes it
has. We don't need to verify all the nodes in all the cases. Sometimes we need
to verify only a set of nodes for a set of branches. We can ignore nodes of
other branches as we are not going to read them.
This patch introduces two attributes to branchcache class. _verifiedbranches is
a set which will tell the branches for which it's head nodes are verified.
_closedverified is a boolean which will tell whether all closednodes are
verified or not.
Another idea which I had was to keep a set of nodes which are verified, but it
will be more ugly and difficult to track things on node level.
Differential Revision: https://phab.mercurial-scm.org/D6156
Pulkit Goyal <pulkit@yandex-team.ru> [Mon, 18 Mar 2019 19:44:55 +0300] rev 42005
branchcache: make entries a private attribute
Differential Revision: https://phab.mercurial-scm.org/D6155
Pulkit Goyal <pulkit@yandex-team.ru> [Mon, 18 Mar 2019 19:31:45 +0300] rev 42004
branchcache: introduce hasbranch()
This will be used to check whether a branch exists or not. This will optimized
in future.
Differential Revision: https://phab.mercurial-scm.org/D6154
Pulkit Goyal <pulkit@yandex-team.ru> [Mon, 18 Mar 2019 19:11:55 +0300] rev 42003
branchmap: drop branchcache.setdefault() (API)
All the callers are updated to call setdefault of branchcache.entries
Differential Revision: https://phab.mercurial-scm.org/D6153
Pulkit Goyal <pulkit@yandex-team.ru> [Mon, 18 Mar 2019 19:01:29 +0300] rev 42002
branchcache: rename itervalues() to iterheads()
The itervalues() exists because branchcache() had a dict interface. Since it no
longer has a dict interface, it makes sense to have better function names.
If a person does not understand how branchcache stores info, it will be hard for
them to guess what itervalues() does.
Differential Revision: https://phab.mercurial-scm.org/D6152
Pulkit Goyal <pulkit@yandex-team.ru> [Mon, 18 Mar 2019 18:59:38 +0300] rev 42001
branchmap: remove the dict interface from the branchcache class (API)
The current branchmap computation involves reading the whole branchmap from
disk, validating all the nodes even if they are not required. This leads to a
lot of time on repos which have large branchmap or a lot of branches. On large
repos, this can validate around 1000's of nodes.
On some operations, like finding whether a branch exists or not, we don't need
to validate all the nodes. Or updating heads for a single branch.
Before this patch, branchcache class was having dict interface and it was hard
to keep track of reads.
This patch removes the dict interface. Upcoming patches will implement lazy
loading and validation of data and implement better API's.
Differential Revision: https://phab.mercurial-scm.org/D6151
Yuya Nishihara <yuya@tcha.org> [Sat, 23 Mar 2019 20:59:07 +0900] rev 42000
test-template: fix stdio mode on Windows
Otherwise, CBOR data would be corrupted. Spotted by Matt Harbison.
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Fri, 22 Mar 2019 12:30:05 -0400] rev 41999
samplehgrcs: update the list of suggested extensions
Back in the day, this was color and pager, both of which are now
default. Churn isn't that popular, but the other four below
(obviously?) are.
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Fri, 22 Mar 2019 12:28:59 -0400] rev 41998
samplehgrcs: clarify which lines should be uncommented
The original wording has confused at least one person. Hopefully it's
clearer this way.
https://stackoverflow.com/questions/55288177/adding-hg-strip-to-hgrc-config-file
Yuya Nishihara <yuya@tcha.org> [Sun, 10 Mar 2019 13:07:36 +0900] rev 41997
templatefilters: add {x|cbor} filter for custom CBOR output
Yuya Nishihara <yuya@tcha.org> [Sun, 10 Mar 2019 12:57:24 +0900] rev 41996
template: add CBOR output format
The whole output is wrapped as an array just like the other serialization
formats. It's an indefinite-length array since the size is unknown while
encoding. Maybe we can add 'cbor-stream' (and 'pickle-stream') as needed.
Martin von Zweigbergk <martinvonz@google.com> [Tue, 19 Mar 2019 23:00:07 -0700] rev 41995
memfilectx: override copysource() instead of using dummy nodeid
The "_copied" property in basefilectx is used by renamed() and
copysource(). committablefilectx (which memfilectx subclasses)
overrides renamed() and writes it in terms of copysource() instead of
_copied. That means that the nodeid part of "_copied" is memfilectx is
unused. Let's instead override copysource() too so we don't need the
"_copied".
Differential Revision: https://phab.mercurial-scm.org/D6159
Martin von Zweigbergk <martinvonz@google.com> [Tue, 19 Mar 2019 22:58:39 -0700] rev 41994
memctx: rename constructor argument "copied" to "copysource" (API)
It's just the path, not the nodeid, so "copysource" seems more
appropriate.
Differential Revision: https://phab.mercurial-scm.org/D6158
Kyle Lippincott <spectral@google.com> [Wed, 13 Mar 2019 20:09:56 -0700] rev 41993
crecord: redraw the screen when starting up chunkselector
Failure to do this can cause screen corruption like:
<headerline>
[X] filename.cc
<several blank lines>
<output from previous iteration of split that happened to be here>
I believe this might only happen in some terminals, and maybe only when using
the "alternate screen". Regardless of the exact conditions to reproduce, it
should be safe to always clear it when starting up and is probably the correct
thing to do anyway :)
Differential Revision: https://phab.mercurial-scm.org/D6131
Kyle Lippincott <spectral@google.com> [Wed, 13 Mar 2019 18:39:45 -0700] rev 41992
crecord: redraw the screen on ctrl-L
This is the normal use of Ctrl-L, so I think this is going to be what most
people expect it to do. We're keeping the adjustment of what line we're scrolled
to as well. I believe both to be necessary to handle otherwise inescapable
situations when we've got screen corruption or edge-cases during window
resizing.
Differential Revision: https://phab.mercurial-scm.org/D6130
Kyle Lippincott <spectral@google.com> [Wed, 13 Mar 2019 18:39:36 -0700] rev 41991
crecord: completely redraw screen when coming back from editor
Differential Revision: https://phab.mercurial-scm.org/D6129
Pulkit Goyal <pulkit@yandex-team.ru> [Wed, 20 Mar 2019 20:42:10 +0300] rev 41990
tests: glob seconds in test-upgrade-repo.t
I had the test failing locally for me with diff showing `1.4s` instead of 0.0s
Differential Revision: https://phab.mercurial-scm.org/D6161
Pulkit Goyal <pulkit@yandex-team.ru> [Wed, 20 Mar 2019 20:39:44 +0300] rev 41989
store: recommend using `hg debugrebuildfncache` is fncache is corrupted
Differential Revision: https://phab.mercurial-scm.org/D6160
Pulkit Goyal <pulkit@yandex-team.ru> [Mon, 18 Mar 2019 14:48:49 +0300] rev 41988
debugsparse: abort if the repository is not sparse instead of ui.status()
This is similar to what narrow extension does.
Differential Revision: https://phab.mercurial-scm.org/D6149
Martin von Zweigbergk <martinvonz@google.com> [Tue, 12 Mar 2019 14:17:41 -0700] rev 41987
revert: option to choose what to keep, not what to discard
I know the you (the reader) are probably tired of discussing how `hg
revert -i -r .` should behave and so am I. And I know I'm one of the
people who argued that showing the diff from the working copy to the
parent was confusing. I think it is less confusing now that we show
the diff from the parent to the working copy, but I still find it
confusing. I think showing the diff of hunks to keep might make it
easier to understand. So that's what this patch provides an option
for.
One argument doing it this way is that most people seem to find `hg
split` natural. I suspect that is because it shows the forward diff
(from parent commit to the commit) and asks you what to put in the
first commit. I think the new "keep" mode for revert (this patch)
matches that.
In "keep" mode, all the changes are still selected by default. That
means that `hg revert -i` followed by 'A' (keep all) (or 'c' in
curses) will be different from `hg revert -a`. That's mostly because
that was simplest. It can also be argued that it's safest. But it can
also be argued that it should be consistent with `hg revert -a`.
Note that in this mode, you can edit the hunks and it will do what you
expect (e.g. add new lines to your file if you added a new lines when
editing). The test case shows that that works.
Differential Revision: https://phab.mercurial-scm.org/D6125
Martin von Zweigbergk <martinvonz@google.com> [Tue, 12 Mar 2019 14:58:35 -0700] rev 41986
patch: include newline at EOF in help text for interactive patch
The lack of a newline means that some "editors" that are useful in
tests, such as `echo "+new line" >> "$1"` don't work. It's obviously
easy to work around it, but newline at EOF seems like a good practice
anyway.
Differential Revision: https://phab.mercurial-scm.org/D6124
Pulkit Goyal <pulkit@yandex-team.ru> [Tue, 19 Mar 2019 16:36:59 +0300] rev 41985
merge with stable
Augie Fackler <raf@durin42.com> [Tue, 19 Mar 2019 09:23:35 -0400] rev 41984
Added signature for changeset 4ea21df312ec
Augie Fackler <raf@durin42.com> [Tue, 19 Mar 2019 09:23:33 -0400] rev 41983
Added tag 4.9.1 for changeset 4ea21df312ec
Sushil khanchi <sushilkhanchi97@gmail.com> [Sun, 03 Mar 2019 20:16:22 +0530] rev 41982
patch: include flag-only file changes in "special" when filtering (issue5864)
This patch fix the issue5864 (or maybe issue5865 too) which occurs during
split (or I should say at the time of filtering the hunks in interactive
mode) where user hits a not ending loop of "no changes to record".
And it's not only the case for split it will happen in every interactive
case for e.g. `hg commit -i` or `hg uncommit -i`
After looking into code I found that when filtering we have some
notation called "special" for the file headers which doesn't contain
any hunk and just contain the header (for e.g. newly added empty file
or deleted file) where the user cannot change the content of operation.
And I think we can put this "flag-only" file change in that same bucket
of "special". But I doubt a bit about the case when a file have flag change
and atleast one hunk then user won't be able to separate the flag change
from hunks.
Changed test file reflect the fixed behaviour.
Differential Revision: https://phab.mercurial-scm.org/D6058
Pulkit Goyal <pulkit@yandex-team.ru> [Mon, 18 Mar 2019 16:56:24 +0300] rev 41981
store: error out if fncache does not ends with a newline
If fncache does not ends with a newline, chunk will not be fully consumed. It
should be a bug somewhere or the fncache is corrupted if that happens. Let's
error out in such cases.
Differential Revision: https://phab.mercurial-scm.org/D6148
Pulkit Goyal <pulkit@yandex-team.ru> [Mon, 18 Mar 2019 14:57:43 +0300] rev 41980
tracked: add documentation about `--import-rules` flag
The documentation is inspired from the `--import-rules` flag of hg debugsparse
command.
Differential Revision: https://phab.mercurial-scm.org/D6150
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 14 Mar 2019 19:13:45 +0000] rev 41979
discovery: fix embarrassing typo in slice definition
The code introduced in e514799e4e07 ended up having a silly bug. The indexing
selected a single item slice picking only p1. The discovery result was still
correct, but the sampling was hampered, sometime leading to much more round
trips being performed.
Fixing this issue restore the previous sampling behavior.
This fix has a negative performance impact on the pathological case the previous
test has been built.
# parent of this changesets
! wall 5.313884 comb 5.310000 user 5.260000 sys 0.050000 (best of 5)
! wall 6.711860 comb 6.710000 user 6.670000 sys 0.040000 (max of 5)
! wall 5.844016 comb 5.842000 user 5.784000 sys 0.058000 (avg of 5)
! wall 5.778635 comb 5.780000 user 5.740000 sys 0.040000 (median of 5)
# With this changesets.
! wall 6.350879 comb 6.350000 user 6.300000 sys 0.050000 (best of 5)
! wall 6.653647 comb 6.660000 user 6.480000 sys 0.180000 (max of 5)
! wall 6.492762 comb 6.494000 user 6.414000 sys 0.080000 (avg of 5)
! wall 6.547577 comb 6.550000 user 6.490000 sys 0.060000 (median of 5)
Changeset e514799e4e07 raised the question of using the "_uncheckedparentrevs"
instead of the current code. So I ran comparative timing:
# old code: 55919b96c02a (e514799e4e07 parent)
! wall 64.078708 comb 64.080000 user 63.160000 sys 0.920000 (best of 5)
! wall 68.296300 comb 68.290000 user 67.410000 sys 0.880000 (max of 5)
! wall 65.899075 comb 65.894000 user 65.082000 sys 0.812000 (avg of 5)
! wall 66.140286 comb 66.130000 user 65.330000 sys 0.800000 (median of 5)
# buggy code: e514799e4e07
! wall 46.605362 comb 46.610000 user 45.880000 sys 0.730000 (best of 5)
! wall 48.619659 comb 48.620000 user 47.890000 sys 0.730000 (max of 5)
! wall 47.350247 comb 47.350000 user 46.672000 sys 0.678000 (avg of 5)
! wall 46.983224 comb 46.980000 user 46.350000 sys 0.630000 (median of 5)
# fixed code: e514799e4e07 with this fix
! wall 55.858460 comb 55.850000 user 55.090000 sys 0.760000 (best of 5)
! wall 59.048805 comb 59.060000 user 58.110000 sys 0.950000 (max of 5)
! wall 57.192639 comb 57.192000 user 56.350000 sys 0.842000 (avg of 5)
! wall 57.056373 comb 57.060000 user 56.160000 sys 0.900000 (median of 5)
# version using uncheckedparents
! wall 56.471916 comb 56.470000 user 55.630000 sys 0.840000 (best of 5)
! wall 58.228793 comb 58.230000 user 57.600000 sys 0.630000 (max of 5)
! wall 57.377583 comb 57.378000 user 56.674000 sys 0.704000 (avg of 5)
! wall 57.008843 comb 57.010000 user 56.330000 sys 0.680000 (median of 5)
So it looks like the overhead from `_uncheckedparentrevs` is not that impactful.
I'll investigate this shortly. I'm almost done updating our benchmark suite
with more meaningful discovery cases.
Pulkit Goyal <pulkit@yandex-team.ru> [Thu, 22 Nov 2018 15:14:24 +0300] rev 41978
store: don't read the whole fncache in memory
In large repositories with lot of files, the fncache grows more than 100 MB and
reading that whole thing into memory slows things down. Let's not read the whole
thing into memory.
This patch changes fncache loading code to read 1 MB at once. Loading 1 MB at
once saves ~1 sec on perffncacheload for our internal repository. I tried
various values such as 0.5 MB, 5 MB, 10 MB but best results were produced using
1 MB as the chunksize.
On a narrow clone with fncache around 40 MB, this patch saves ~0.04 seconds on
average on perffncacheload.
To test the code, I have coded an extension in test-fncache.t which set
chunksize to 1 byte, and the test passes with that.
Differential Revision: https://phab.mercurial-scm.org/D5296
Matt Harbison <matt_harbison@yahoo.com> [Sat, 16 Mar 2019 14:40:21 -0400] rev 41977
record: prevent commits that don't pick up dirty subrepo changes (issue6102)
This path covers interactive mode for commit, amend, and shelve, as well as the
deprecated record extension. Since shelf creation uses commit without -S in the
non-interactive case, aborting here should be OK. (I didn't check what happens
to non interactive shelve creation if `ui.commitsubrepos=True` is set.)
subrepoutil.precommit() will abort on a dirty subrepo if the config option isn't
set, but the hint recommends using --subrepos to commit. Since only the commit
command currently supports that option, the error has to be raised here to omit
the hint.
Doing the check before asking about all of the hunks in the MQ test seems like
an improvement on its own. There's probably an additional check on this path
that can be removed.
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 08 Mar 2019 10:20:33 -0800] rev 41976
wix: restore COPYING.rtf
8427fea04017 accidentally blew away the content of this file.
As part of restoring the content, I updated the copyright year
to 2019.
Differential Revision: https://phab.mercurial-scm.org/D6098
Yuya Nishihara <yuya@tcha.org> [Sun, 17 Mar 2019 12:43:45 +0900] rev 41975
test-https: add some more known failure messages of client certs (issue6030)
I don't think the exact error message is important here. On Debian sid,
ECONNRESET is raised, and "[SSL] tlsv13 alert certificate required" on NetBSD.
Yuya Nishihara <yuya@tcha.org> [Sun, 17 Mar 2019 12:37:57 +0900] rev 41974
test-https: turn off system OpenSSL configuration
This mostly fixes the test failure on Debian sid where TLS 1.0 and 1.1 are
disabled by default.
https://sources.debian.org/patches/openssl/1.1.1a-1/Set-systemwide-default-settings-for-libssl-users.patch/
$OPENSSL_CONF could be set by run-tests.py, but the other tests should work
without a "legacy" TLS, so I decided to not.
Pulkit Goyal <pulkit@yandex-team.ru> [Wed, 27 Feb 2019 16:29:48 +0300] rev 41973
store: move logic to check for invalid entry in fncache to own function
This helps separate the original reading logic from the one which finds for an
invalid entry.
Differential Revision: https://phab.mercurial-scm.org/D6030
Ian Moody <moz-ian@perix.co.uk> [Sat, 09 Mar 2019 02:52:49 +0000] rev 41972
py3: add test-phabricator.py to python3-whitelist
Differential Revision: https://phab.mercurial-scm.org/D6114
Ian Moody <moz-ian@perix.co.uk> [Sat, 09 Mar 2019 02:18:49 +0000] rev 41971
py3: convert to/from bytes/unicode for json.(dump|load)s in debugcallconduit
Differential Revision: https://phab.mercurial-scm.org/D6113
Ian Moody <moz-ian@perix.co.uk> [Fri, 08 Mar 2019 18:30:12 +0000] rev 41970
py3: use pycompat.byteskwargs on opts in phabricator.py
Differential Revision: https://phab.mercurial-scm.org/D6107
Boris Feld <boris.feld@octobus.net> [Fri, 21 Dec 2018 17:12:39 +0100] rev 41969
watchman: ignore some of watchman errors
Don't display 'illegal_fstypes' errors. In environments with network
filesystems, the error messages are quickly pilling up and polluting outputs.
Differential Revision: https://phab.mercurial-scm.org/D5955
Boris Feld <boris.feld@octobus.net> [Fri, 21 Dec 2018 17:10:54 +0100] rev 41968
watchman: add the possibility to set the exact watchman binary location
This is necessary to make rolling releases of new watchman versions across
users.
Differential Revision: https://phab.mercurial-scm.org/D5954
Martin von Zweigbergk <martinvonz@google.com> [Fri, 15 Mar 2019 22:18:35 -0700] rev 41967
context: use wdirhex constant instead of calculating it
Differential Revision: https://phab.mercurial-scm.org/D6143
Martin von Zweigbergk <martinvonz@google.com> [Wed, 13 Mar 2019 11:30:04 -0700] rev 41966
split: use the new movedirstate() we now have in scmutil
This avoids unnecessarily touching the working copy when splitting the
parent of the working copy. That also makes the test-removeemptydirs.t
case invalid, so we can just delete it.
Differential Revision: https://phab.mercurial-scm.org/D6127
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 14 Mar 2019 00:40:11 +0000] rev 41965
manifestcache: use `wcache` directory for manifest cache
The manifest full text cache is tightly related to the working copy. We should
use the `wcache` directory for it, instead of the `cache`. Otherwise, multiple
shares would keep overwriting each other cache entry and we loose its benefit.
This is also more consistent with the fact this cache file is protected by
`wlock`.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 15 Mar 2019 15:07:43 +0000] rev 41964
manifestcache: protect write with `wlock` instead of `lock`
The `wlock` is taken by both `update` and `commit` type operation. This would
help persisting the cache more aggressively.
An explicit test is introduced. However, we can already see the effect of this
change on earlier test output.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 14 Mar 2019 09:12:55 +0000] rev 41963
manifestcache: clear the cache before testing the debug command
Right now the cache is empty before this section of the test. However, we are
about to improve the persistence of the cache (putting it under `wllock`,
intead of `lock`). So we install the cleanup before.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 15 Mar 2019 12:17:30 +0000] rev 41962
manifestcache: abstract the filename in a class attribute
This make the code clearer and simpler to update.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 15 Mar 2019 09:07:23 +0000] rev 41961
manifestcache: skip setup earlier if we don't have the lock
There a no point preparing a closure if we are not going to use it.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 14 Mar 2019 11:46:18 +0000] rev 41960
manifestcache: test the cache is warm after a commit
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 15 Mar 2019 13:52:36 +0000] rev 41959
manifestcache: stop altering the lru cache order while displaying it
Accessing value with `.get` alter the iteration order and make the output of
the debug command misbehave, showing multiple entry twice.
We need more than 2 entry to see the bug, so there are not test change. Later
test will introduce a third entry and would fail without this fix.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 15 Mar 2019 13:52:56 +0000] rev 41958
manifestcache: support multiple cache addition in one debug command run
This is more practical.
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 14 Mar 2019 18:11:22 -0700] rev 41957
wix: autogenerate wxs file for library files
Currently, dist.wxs contains an enumeration of .pyd and .dll
files staged to dist/lib by py2exe.
Having a manual list of files is error prone, as things can
easily get out of sync (as the previous commit demonstrates).
This is especially an issue for TortoiseHG, which ships a
number of custom modules, which may pull in additional dependencies.
Let's prevent this problem from manifesting by dynamically
generating a .wxs file containing the .pyd and .dll files staged
by py2exe.
Differential Revision: https://phab.mercurial-scm.org/D6139
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 14 Mar 2019 17:59:51 -0700] rev 41956
wix: introduce variable to hold path to wix packaging directory
For convenience.
Differential Revision: https://phab.mercurial-scm.org/D6138
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 14 Mar 2019 18:25:23 -0700] rev 41955
wix: package missing .dll and .pyd files
dist.wxs is currently missing some .pyd and .dll files which are
picked up and staged by py2exe. This means that the WiX installer
is missing some Python extension modules and their dependencies which
are referenced by Mercurial or a Python package distributed with
it.
This commit adds the missing files to the WiX installer.
Differential Revision: https://phab.mercurial-scm.org/D6137
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 14 Mar 2019 18:25:07 -0700] rev 41954
setup: exclude crypt32.dll in py2exe builds
py2exe is picking up crypt32.dll as a dependency and is including
the DLL in the dist/lib directory, where it can get picked up by an
installer and distributed.
crypt32.dll is a core Windows DLL since Windows XP. We don't need
to distribute it.
Differential Revision: https://phab.mercurial-scm.org/D6136
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 14 Mar 2019 13:27:37 -0700] rev 41953
packaging: don't bundle DLLs in py2exe library.zip for x86 builds
I had ported the x86/x64 behavior difference from the Inno
Setup installer files. Why things were this way, I'm not sure.
The WiX configuration files are expecting to have standalone
DLL files for both configurations. And the 32-bit WiX installers
were broken due to missing DLLs.
Let's standardize on standalone DLL files on all configurations
for consistency. I /think/ this will be faster, as I /think/
py2exe binaries would have to extract the DLL to a temporary file
in order to load it. But I'm not 100% sure about that.
Differential Revision: https://phab.mercurial-scm.org/D6135
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 14 Mar 2019 18:14:33 -0700] rev 41952
packaging: convert files to LF
My editor accidentally wrote CRLF line endings because I authored
this code on Windows. Derp.
I'm kinda surprised no linters caught this...
# no-check-commit to avoid false positive for foo_bar names
Differential Revision: https://phab.mercurial-scm.org/D6134
Martin von Zweigbergk <martinvonz@google.com> [Wed, 13 Mar 2019 10:51:40 -0700] rev 41951
dirstate: remove obsolete reference to dirstate.beginparentchange
The only valid API since 265e91da56fd (dirstate: drop deprecated
methods (API), 2018-02-02) is the context manager returned from
dirstate.parentchange().
Differential Revision: https://phab.mercurial-scm.org/D6126
Ian Moody <moz-ian@perix.co.uk> [Sat, 09 Mar 2019 00:44:26 +0000] rev 41950
py3: use pycompat.iterbytestr to convert memoryview slice to bytestring
Otherwise ch is the int value of the byte in py3 rather than the actual
character.
Differential Revision: https://phab.mercurial-scm.org/D6103
Martin von Zweigbergk <martinvonz@google.com> [Thu, 14 Mar 2019 14:46:29 -0700] rev 41949
rebase: fix crash with in-memory rebase and copies
When using regular on-disk rebase, filectx.markcopies() calls to
dirstate.copy(), which happily records the copy. Then it's simply
ignored if it doesn't matter for the commit (as in the test case I
added in the previous patch). Let's do the same for overlayworkingctx.
Differential Revision: https://phab.mercurial-scm.org/D6133
Martin von Zweigbergk <martinvonz@google.com> [Thu, 14 Mar 2019 13:53:20 -0700] rev 41948
test: demonstrate crash with in-memory rebase and copies
In the added test case, there is a merge commit that has one obsolete
parent with a rename. Since the rename is not in the other parent,
pathcopies() from that other parent will include the copy. Then when
we try to rebase this merge commit onto another commit that has the
same content changes, but no tracking of the rename (because it was
done with "hg remove; hg add" instead of "hg mv"), we try to propagate
the copy information. That fails because overlayworkingctx expects a
file to be modified if it's going to have copy information.
Differential Revision: https://phab.mercurial-scm.org/D6132
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 14 Mar 2019 09:12:46 +0000] rev 41947
manifestcache: actually honor --clear
Before this change, the --clear flag was not clearing the on disk cache.
(We also remove the extra verbosity when using --clear. Same as what we did for --add)
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 14 Mar 2019 10:58:53 +0000] rev 41946
manifestcache: make sure the entry are ordered by access time
This is an LRU cache, let us make sure of that.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 14 Mar 2019 09:12:27 +0000] rev 41945
manifestcache: adding a second distinct entry
Let makes sure the cache can hold multiple value.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 14 Mar 2019 10:53:28 +0000] rev 41944
manifestcache: test that adding the same entry twice do not duplicates it
Simple sanity check.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 14 Mar 2019 09:11:41 +0000] rev 41943
manifestcache: do not display data when using --add
If the command invocation is about adding a new entry, we should remain terse
(the same as we do for many commands).
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 14 Mar 2019 10:43:01 +0000] rev 41942
manifestcache: only lock the repository if the debug command touch the cache
Not doing so had two consequences:
1) the command cannot be run on read only repositories,
2) when using --add on an empty cache, the command crash prematurely trying to
read the cache file on disk.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 14 Mar 2019 10:24:51 +0000] rev 41941
manifestcache: further fix to debug command output
Removing more capital letters. The output will get a test once other issues get
fixed.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 14 Mar 2019 09:11:18 +0000] rev 41940
manifestcache: test and fix some output of the debug command
The message was lacking an end of line. In addition we do not capitalize output
in Mercurial.
Kyle Lippincott <spectral@google.com> [Thu, 27 Dec 2018 13:36:17 -0800] rev 41939
chunkselector: fix typos in instructions when user reviews patch
Differential Revision: https://phab.mercurial-scm.org/D6121
Martin von Zweigbergk <martinvonz@google.com> [Mon, 11 Mar 2019 14:04:48 -0700] rev 41938
scmutil: document matcher argument of movedirstate()
Differential Revision: https://phab.mercurial-scm.org/D6120
Martin von Zweigbergk <martinvonz@google.com> [Mon, 11 Mar 2019 09:42:29 -0700] rev 41937
uncommit: move _movedirstate() to scmutil for reuse
The function should be applicable generically when moving from one
commit to another. I'll try to add more callers when I find time.
I'm not convinced it's handling all the cases correctly, but we should
have a generic function for this kind of operation, so I think it
belongs somewhere in core (not in the uncommit extension).
Differential Revision: https://phab.mercurial-scm.org/D6119
Martin von Zweigbergk <martinvonz@google.com> [Mon, 11 Mar 2019 09:20:26 -0700] rev 41936
copies: remove dependency on scmutil by directly using match.exact()
I want to add a dependency from scmutil.copies(), so I need to remove
this dependency first.
Differential Revision: https://phab.mercurial-scm.org/D6118
Martin von Zweigbergk <martinvonz@google.com> [Mon, 11 Mar 2019 09:35:36 -0700] rev 41935
uncommit: convert _fixdirstate() into _movedirstate()
_fixdirstate() already also updates to the given commit, so let's
rename it to _movedirstate(). Also update the documentation and drop
the unnecessary "curctx" argument, since that should always be
repo['.'].
Differential Revision: https://phab.mercurial-scm.org/D6117
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 11 Mar 2019 02:34:12 +0100] rev 41934
updatecaches: also warm the tags caches
Resolving any name requires the tags cache to be warm. We make sure that `hg
debugupdatecache` warm the tag cache entry too.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 11 Mar 2019 02:32:21 +0100] rev 41933
updatecaches: also warm revbranchcache for filtered revisions
We are in the "full" case, so we better warm everything we can.
Sushil khanchi <sushilkhanchi97@gmail.com> [Wed, 13 Feb 2019 15:50:14 +0530] rev 41932
copies: handle a case when both merging csets are not descendant of merge base
This patch fix the behaviour of fullcopytracing algorithm in the case
when both the merging csets are not the descendant of merge base.
Although it seems to be the rare case when both the csets are not
descendant of merge base. But it can be seen in most of cases of
content-divergence in evolve extension, where merge base is the common
predecessor.
Previous patch added a test where this algorithm can fail to continue
because of an assumption that only one of the two csets can be dirty.
This patch fix that error.
For refrence I suggest you to look into the previous discussion held
on a patch sent by Pulkit: https://phab.mercurial-scm.org/D3896
Differential Revision: https://phab.mercurial-scm.org/D5963
Sushil khanchi <sushilkhanchi97@gmail.com> [Thu, 14 Feb 2019 16:09:43 +0530] rev 41931
copies: add test that makes both the merging csets dirty and fails
This patch is a part of series which is about the case when both the merging
csets are not descendant of merge base. The existing code assumes if c1 is
dirty there shouldn't be any partial copies from c2 i.e both2['incomplete']
and same for c2, if c2 is dirty both1['incomplete'] should be empty,
but this is not the right assumption.
Now as we know we can have both c1 and c2 dirty at the same time, it
is possible that c1 is dirty and both2['incomplete'] has some value.
Or if c2 is dirty and both1['incomplete'] has some value.
Added test shows that because of this assumption it could fail.
Differential Revision: https://phab.mercurial-scm.org/D5962
Sushil khanchi <sushilkhanchi97@gmail.com> [Thu, 14 Feb 2019 17:11:35 +0530] rev 41930
copies: add test that makes both the merging csets dirty and run w/o error
This series of patches is to cover a case in fullcopytracing algorithms
where both the merging csets are not descendant of merge base.
In this algorithm we call a merging cset "dirty" if that cset is not the
descendant of merge base. That said, added test in this patch cover case
when both the merging csets are "dirty".
Actually this case of "both dirty" was encountered by Pulkit when he was
working on content-divergence where it is possible that both the csets
are not descendant of merging base.
For reference you can look into: https://phab.mercurial-scm.org/D3896
As this test run fine without any error and correctly traced the copies, I
added this test to make sure that it doesn't break even after I will modify
some code in next patches to fix an error. Next patch adds the tests where
this algorithm throws an error for the same case of "both dirty".
Differential Revision: https://phab.mercurial-scm.org/D5961
Matt Harbison <matt_harbison@yahoo.com> [Sun, 10 Mar 2019 16:51:21 -0400] rev 41929
tests: stabilize test-bundle.t on Windows
Similar to 92055d539e49.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 10 Mar 2019 19:01:56 +0100] rev 41928
discovery-helper: use reflink copy if available
A reflink copy will copy the files "as usual" but keep using the same data block
underneath. This is only supported by "copy on write" file system like btrfs or
zfs.
This will achieve similar performance that the existing hardlink clone that
Mercurial performs with the same initial space saving. However, it will behave
better on revlogs start being touch by strip. Instead of duplicating all data in
the touched revlogs, only the block actually affected by the strip will be
duplicated. This save a lot of space when building many variants of large
repositories.
The --reflink=always flag make sure the `cp` call fails if reflink copies are
not supported. Falling back to local clone.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 10 Mar 2019 18:52:22 +0100] rev 41927
discovery-helper: bail out if destination already exists
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 10 Mar 2019 18:50:38 +0100] rev 41926
discovery-helper: move repository creation in a function
This makes it easier to update this duplicated code.
(we do a small output fix as we go)
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 08 Mar 2019 21:38:57 +0100] rev 41925
discovery-helper: add an extra argument to generate only one repo
This is useful to generate left and right in parallel when dealing with very
large repositories.
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 08 Mar 2019 10:29:48 -0800] rev 41924
wix: remove enum and future packages
These were cargo culted from the THG installer code. I'm not sure
what needs them in THG land. But the official MSIs certainly do
not - at least not as direct dependencies.
.. bc::
The Windows MSI installers no longer include the enum and future
Python packages.
Differential Revision: https://phab.mercurial-scm.org/D6101
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 08 Mar 2019 10:27:40 -0800] rev 41923
wix: remove pywin32
This dependency was for ancient Mercurial versions. We recently
removed it from the Inno Setup installers. So let's remove it
from the WiX installers as well.
.. bc::
The Windows MSI installers no longer include the pywin32 Python
package.
Differential Revision: https://phab.mercurial-scm.org/D6100
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 08 Mar 2019 10:25:05 -0800] rev 41922
wix: remove sphinx and dependencies
Sphinx was cargo culted into our install environment as part of
emulating TortoiseHG's behavior.
THG seems to install Sphinx in order to generate THG specific
documentation.
We don't appear to need Sphinx or any of its dependencies in
the official WiX installers. So remove it.
This shaves ~1MB off the size of the MSI installers.
.. bc::
The Windows MSI installers no longer include the Python
sphinx package and its various dependencies.
Differential Revision: https://phab.mercurial-scm.org/D6099
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 08 Mar 2019 10:48:22 -0800] rev 41921
wix: functionality to automate building WiX installers
Like we did for Inno Setup, we want to make it easier to
produce WiX installers. This commit does that.
We introduce a new hgpackaging.wix module for performing
all the high-level tasks required to produce WiX installers.
This required miscellaneous enhancements to existing code in
hgpackaging, including support for signing binaries.
A new build.py script for calling into the module APIs has been
created. It behaves very similarly to the Inno Setup build.py
script.
Unlike Inno Setup, we didn't have code in the repo previously
to generate WiX installers. It appears that all existing
automation for building WiX installers lives in the
https://bitbucket.org/tortoisehg/thg-winbuild repository - most
notably in its setup.py file. My strategy for inventing the
code in this commit was to step through the code in that repo's
setup.py and observe what it was doing. Despite the length of
setup.py in that repository, the actual amount of steps required
to produce a WiX installer is actually quite low. It consists
of a basic py2exe build plus invocations of candle.exe and
light.exe to produce the MSI.
One rabbit hole that gave me fits was locating the Visual Studio
9 C Runtime merge modules. These merge modules are only present
on your system if you have a full Visual Studio 2008 installation.
Fortunately, I have a copy of Visual Studio 2008 and was able
to install all the required updates. I then uploaded these merge
modules to a personal repository on GitHub. That is where the
added code references them from. We probably don't need to
ship the merge modules. But that is for another day.
The installs from the MSIs produced with the new automation
differ from the last official MSI in the following ways:
* Our HTML manual pages have UNIX line endings instead of Windows.
* We ship modules in the mercurial.pure package. It appears the
upstream packaging code is not including this package due to
omission (they supply an explicit list of packages that has
drifted out of sync with our setup.py).
* We do not ship various distutils.* modules. This is because
virtualenvs have a custom distutils/__init__.py that automagically
imports distutils from its original location and py2exe gets
confused by this. We don't use distutils in core Mercurial and
don't provide a usable python.exe, so this omission should be
acceptable.
* The version of the enum package is different and we ship
an enum.pyc instead of an enum/__init__.py.
* The version of the docutils package is different and we
ship a different set of files.
* The version of Sphinx is drastically newer and we ship a
number of files the old version did not. (I'm not sure why
we ship Sphinx - I think it is a side-effect of the way the
THG code was installing dependencies.)
* We ship the idna package (dependent of requests which is a
dependency of newer versions of Sphinx).
* The version of imagesize is different and we ship an
imagesize.pyc instead of an imagesize/__init__.pyc.
* The version of the jinja2 package is different and the sets
of files differs.
* We ship the packaging package, which is a dependency for Sphinx.
* The version of the pygments package is different and the sets
of files differs.
* We ship the requests package, which is a dependency for Sphinx.
* We ship the snowballstemmer package, which is a dependency for
Sphinx.
* We ship the urllib3 package, which is a dependency for requests,
which is a dependency for Sphinx.
* We ship a newer version of the futures package, which includes a
handful of extra modules that match Python 3 module names.
# no-check-commit because foo_bar naming
Differential Revision: https://phab.mercurial-scm.org/D6097
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 07 Mar 2019 15:37:42 -0800] rev 41920
wix: move contrib/wix to contrib/packaging/wix
We're trying to consolidate all our packaging code into
contrib/packaging. Let's move the WiX files there.
Differential Revision: https://phab.mercurial-scm.org/D6096
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 08 Mar 2019 10:33:05 -0800] rev 41919
wix: remove hg.cmd
This file is not referenced anywhere AFAICT.
Differential Revision: https://phab.mercurial-scm.org/D6095
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 07 Mar 2019 14:02:02 -0800] rev 41918
setup: include hgext3rd package in py2exe builds
This is a core Mercurial package and we should always ship it.
Differential Revision: https://phab.mercurial-scm.org/D6094
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 07 Mar 2019 13:47:28 -0800] rev 41917
setup: properly install build_hgextindex for py2exe builds
Because the hgbuild class has a private copy of build.sub_commands,
modifying build.sub_commands from this code effectively resulted
in a no-op. Registering the sub-command on hgbuild actually results
in the sub-command running when building Mercurial.
Differential Revision: https://phab.mercurial-scm.org/D6093
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 07 Mar 2019 12:15:32 -0800] rev 41916
setup: configure py2exe config via environment variables
The Inno Setup and WiX installers ship a different set of packages
with py2exe builds. And there are multiple WiX installer variants
(e.g. TortoiseHG).
Since there are multiple variants of py2exe configs and they
can be defined by entities not in our repository, let's
provide a mechanism for setup.py to supplement behavior via
environment variables. This is slighly less hacky than a setup.cfg
file IMO since the caller doesn't need to worry about mutating
global state of the source directory.
Differential Revision: https://phab.mercurial-scm.org/D6092
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 07 Mar 2019 15:43:54 -0800] rev 41915
packaging: extract py2exe functionality to own module
py2exe builds are shared between Inno Setup and WIX. We'll
want the logic for performing py2exe builds to be reusable
across the code for both installers.
This commit extracts the py2exe-specific functionality into
its own module.
There's definitely room to customize things further. This will
be done in future commits, as necessary. (I'm not even sure what
customizations WIX will require yet. Presumably a lot.)
Differential Revision: https://phab.mercurial-scm.org/D6091
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 07 Mar 2019 10:49:59 -0800] rev 41914
packaging: extract python exe info to own function
This is generic functionality. We'll need it for WIX.
As part of the port, we expose the full version and return
the data as a dict.
Differential Revision: https://phab.mercurial-scm.org/D6090
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 07 Mar 2019 10:36:20 -0800] rev 41913
packaging: don't use temporary directory
We were no longer doing anything with it after extracting
virtualenv and py2exe to the build directory.
Differential Revision: https://phab.mercurial-scm.org/D6089
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 07 Mar 2019 10:35:20 -0800] rev 41912
packaging: extract virtualenv and py2exe to build directory
The build directory is essentially a cache. We can extract
the virtualenv and py2exe package sources to this directory.
Differential Revision: https://phab.mercurial-scm.org/D6088
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 07 Mar 2019 15:43:14 -0800] rev 41911
packaging: move Inno Setup core logic into a module
Aspects of building the Inno Setup and WIX installers are shared.
It will make sense for them to share code.
Plus, having code in a reusable library (as opposed to a standalone
script) is just a better approach.
This commit moves the core logic to build the Inno Setup installer
into the hgpackaging package. inno/build.py is now a simple frontend
script that calls into a module to do the bulk of the work.
As part of this change, I also found a typo in build() where it was
referencing "iscc" instead of "iscc_exe." Because "iscc" was in
the global scope via the only caller, things just happened to work
before. Another benefit of always using functions and not putting
global code for __main__ in the same file as library code.
Differential Revision: https://phab.mercurial-scm.org/D6087
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 07 Mar 2019 10:22:09 -0800] rev 41910
packaging: move find_vc_runtime_files() into hgpackaging.util
In preparation for moving the bulk of the Inno Setup code into
hgpackaging.
Differential Revision: https://phab.mercurial-scm.org/D6086
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 07 Mar 2019 10:20:37 -0800] rev 41909
packaging: move DOWNLOADS dict to hgpackaging.downloads
We'll want to keep state in sync between multiple packaging tools.
It makes sense to share a central data structure defining downloads.
We also change the function to return the downloads entry so
callers don't have to access the global DOWNLOADS in the new
location.
Differential Revision: https://phab.mercurial-scm.org/D6085
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 07 Mar 2019 15:42:32 -0800] rev 41908
packaging: split downloading code into own module
As we will introduce more code to support packaging, it will be
useful to have download code in its own module.
Differential Revision: https://phab.mercurial-scm.org/D6084
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 07 Mar 2019 10:10:04 -0800] rev 41907
packaging: establish hgpackaging package
Previously, contrib/packaging behaved as a root to a
package directory and we had a "packagingutil" module. As I
work more on packaging code, we'll want to have more code
shared between different packaging tools. I think it makes
sense to have a single package containing multiple modules
than multiple top-level modules.
This commit establishes an "hgpackaging" package by moving
the existing packagingutil code to it.
Differential Revision: https://phab.mercurial-scm.org/D6083
Ian Moody <moz-ian@perix.co.uk> [Sat, 09 Mar 2019 02:07:09 +0000] rev 41906
py3: use % instead of .format() on a bytestring
Differential Revision: https://phab.mercurial-scm.org/D6112
Ian Moody <moz-ian@perix.co.uk> [Fri, 08 Mar 2019 22:26:43 +0000] rev 41905
py3: use r'' for group name arguments to MatchObjects in phabricator.py
MatchObject group names are strings, not bytes. Using bytes in py3 leads to an
IndexError.
Differential Revision: https://phab.mercurial-scm.org/D6111
Ian Moody <moz-ian@perix.co.uk> [Sat, 09 Mar 2019 01:58:51 +0000] rev 41904
py3: use %d instead of %s when formatting an int into a byte string
Differential Revision: https://phab.mercurial-scm.org/D6110
Ian Moody <moz-ian@perix.co.uk> [Sat, 09 Mar 2019 01:53:53 +0000] rev 41903
py3: only pass unicode to json.dumps in writediffproperties
Differential Revision: https://phab.mercurial-scm.org/D6109
Ian Moody <moz-ian@perix.co.uk> [Sat, 09 Mar 2019 01:30:44 +0000] rev 41902
py3: fix a few "dict keys as str instead of bytes" issues in phabricator.py
Differential Revision: https://phab.mercurial-scm.org/D6108
Ian Moody <moz-ian@perix.co.uk> [Sat, 09 Mar 2019 01:00:25 +0000] rev 41901
py3: convert URL to str before passing it to request
Differential Revision: https://phab.mercurial-scm.org/D6106
Ian Moody <moz-ian@perix.co.uk> [Fri, 08 Mar 2019 23:45:12 +0000] rev 41900
py3: convert indexes into bytes when enumerating lists in urlencodenested
Otherwise it'll try to insert them them into a %s slot in a b'' later and fail.
Differential Revision: https://phab.mercurial-scm.org/D6105
Ian Moody <moz-ian@perix.co.uk> [Fri, 08 Mar 2019 23:48:49 +0000] rev 41899
py3: don't try and format a bare dict into a byte string in callconduit
Differential Revision: https://phab.mercurial-scm.org/D6104
Ian Moody <moz-ian@perix.co.uk> [Fri, 08 Mar 2019 17:57:59 +0000] rev 41898
py3: use fsencode for vcr recording paths and strings for custom_patches args
This fixes phabricator.py's vcrcommand under py3
Differential Revision: https://phab.mercurial-scm.org/D6102
Ian Moody <moz-ian@perix.co.uk> [Sat, 02 Mar 2019 18:48:23 +0000] rev 41897
phabricator: convert conduit response JSON unicode to bytes inside callconduit
Previously the byte conversion was happening piecemeal in callers, and in the
case of createdifferentialrevision not at all, leading to UnicodeEncodeErrors
when trying to phabsend a commit with a description containing characters not
representable in ascii. (issue6040)
Remove all the scattered encoding.unitolocal calls and perform it once, inside
callconduit, on the entire response dict recursively before returning it, in
keeping with the strategy of converting at the earliest opportunity. Convert all
keys used on returned object to bytes.
Modify the phabsend tests to test this by adding a € to the commit message of
alpha.
Differential Revision: https://phab.mercurial-scm.org/D6044
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 09 Feb 2019 23:01:30 +0100] rev 41896
transaction: include txnname in the hookargs dictionary
There is no reason to not include the txnname alongside the txnid in all case.
The python hooks already have them, so aligning the the shell hooks seems it
could be useful in the future.
(I don't have a strong opinion about this, we can also decide to never align the
python and shell hooks and this and I'll drop this patch).
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 08 Mar 2019 00:00:44 +0100] rev 41895
discovery-helper: reflect argument value in the name of the results
It is common to create multiple pairs of repositories using different argument
values. Recording the argument value in the results names has two main
advantages:
* It is easy to remember the value used to create a pair,
* It get simpler to create multiple pair at the same time from the same source.
Previously, running: `./discovery-helper.sh pypy 50 10` would create a
`pypy-left` and `pypy-right` repository. Now it will create `pypy-50h-10d-left`
and `pypy-50h-10d-right`.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 07 Mar 2019 17:21:22 +0100] rev 41894
discovery-helper: echo the stripped revsets early
Having them printed early make it easy for a user to just grab the generated
revset and directly uses them
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 07 Mar 2019 17:15:15 +0100] rev 41893
contrib: move the `discovery-helper.sh` script in`perf-utils` directory
The script appeared before the directory. However the directory exists for this
kind of script. We move it there.
Matt Harbison <matt_harbison@yahoo.com> [Sat, 09 Mar 2019 12:55:24 -0500] rev 41892
tests: stabilize test-split.t for Windows
It looks like there will be additional problems beyond this trivial fix, but
this should make the bot green again.
Matt Harbison <matt_harbison@yahoo.com> [Thu, 07 Mar 2019 22:14:22 -0500] rev 41891
tests: stabilize test-share.t on Windows
PYTHON was not getting mangled for MSYS style paths, and remote was spitting out
remote: 'C' is not recognized as an internal or external command,
remote: operable program or batch file.
(once -q was removed). Additionally, this should fix a failure with py3 because
of spaces in the path.
Sushil khanchi <sushilkhanchi97@gmail.com> [Sun, 03 Mar 2019 19:46:59 +0530] rev 41890
split: add tests which demonstrate the issue5864
Differential Revision: https://phab.mercurial-scm.org/D6057
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 07 Mar 2019 01:28:24 +0100] rev 41889
discovery: clarify why the caching of children is valid
Yuya Nishihara pointed out that the code looks wrong without this clarification.
(And, unsurprisingly, Yuya is right)
Martin von Zweigbergk <martinvonz@google.com> [Wed, 06 Mar 2019 15:43:52 -0800] rev 41888
tests: clarify test setup test in test-uncommit.t
I assume the "hg uncommit b" is there to prove that the working copy
is dirty before we try "hg uncommit --allow-dirty-working-copy b". It
seems clearer to put that check just before we run the actual test.
Differential Revision: https://phab.mercurial-scm.org/D6078
Martin von Zweigbergk <martinvonz@google.com> [Wed, 06 Mar 2019 15:35:40 -0800] rev 41887
tests: fix a stale reference to experimental.uncommitondirtywdir
These tests no longer test the config option, they test the command
line flag.
Differential Revision: https://phab.mercurial-scm.org/D6077
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 28 Feb 2019 01:49:10 +0100] rev 41886
discovery: explicitly use `undecided` for the children mapping
Recent performance achievements makes the assumption that the `undecided` set
is used for sampling. That assumption is always true in practice. We stop
pretending that taking anything else would make sense and we directly use the
`undecided` set from the object. This provides a more honest API.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 28 Feb 2019 01:48:20 +0100] rev 41885
discovery: cache the children mapping used during each discovery
During discovery, the `undecided` set keep shrinking. Therefore, the map
computed for an iteration N will be valid for iteration N+1. Instead of
computing the same data over and over we cache it the first time.
Our private pathological case speed up from about 7.5 seconds to about 6.3
seconds.
(starting from over 70s at the start of the full series)
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 28 Feb 2019 01:15:45 +0100] rev 41884
discovery: move children computation in its own method
This clarifies the main logic and starts to pave the way to some caching.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 05 Mar 2019 15:39:54 +0100] rev 41883
discovery: simplify the building of the children mapping
Since we only care about the revisions inside the set we are sampling, we can
use simpler code (and probably sightly faster).
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 05 Mar 2019 15:52:14 +0100] rev 41882
discovery: simply walk the undecided revs when building the children mapping
The sampling only care about revisions in the undecided set, so building children
relationship within this set is sufficient.
The set of undecided changesets can be much smaller than the full span from its
smallest item to the tip of the repository. This restriction can significantly
speed up operations in some cases.
For example, on our private pathological case, this speeds things up from about
53 seconds to about 7.5 seconds.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 28 Feb 2019 00:56:27 +0100] rev 41881
discovery: use a lower level but faster way to retrieve parents
We already know that no revision in the undecided set are filtered, so we can
skip multiple checks and directly access lower level data.
In a private pathological case, this improves the timing from about 70 seconds
to about 50 seconds. There are other actions to be taken to improve that case,
however this gives an idea of the general overhead.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 28 Feb 2019 00:12:12 +0100] rev 41880
discovery: avoid computing identical sets of heads twice
The very same set of heads is computed in the previous statement, it seems more
efficient to just copy that result.
Georges Racinet <georges.racinet@octobus.net> [Wed, 27 Feb 2019 23:55:19 +0100] rev 41879
discovery: moved sampling functions inside discovery object
In this patch, we transform the sampling functions into
methods of the `partialdiscovery` class in the Python case.
This will provide multiple benefit. For example we can keep some cache from one
sampling to another. In addition this will help the Oxidation work as all graph
traversal related logic will be contained in a single object.
Georges Racinet <georges.racinet@octobus.net> [Wed, 27 Feb 2019 23:45:06 +0100] rev 41878
discovery: rename `srvheads` to `knownsrvheads`
The `srvheads` variable only contains the known set of remove heads. Renaming
the variable make it clearer.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 06 Mar 2019 14:43:02 +0100] rev 41877
verify: small refactoring and documentation in `_verifymanifest`
Small changes to make this area of code clearer.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 06 Mar 2019 12:39:44 +0100] rev 41876
verify: document the `_verifymanifest` method
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 06 Mar 2019 12:21:58 +0100] rev 41875
verify: document `_verifychangelog`
We document the method input, output and checks.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 06 Mar 2019 14:15:19 +0100] rev 41874
verify: rename the `checklog` to `_checkrevlog`
The method is for internal use only. In addition we make the method name
explicitly contains `revlog` to make it clearer it is checking higher level
revlog properties.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 06 Mar 2019 14:10:23 +0100] rev 41873
verify: document the `checklog` method
Let us add details about what the function is expected to do.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 06 Mar 2019 14:07:27 +0100] rev 41872
revlog: add some documentation to the `checksize` method
I had to look at it, so I figured I would leave some documentation for the next
person seeking information.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 06 Mar 2019 12:20:50 +0100] rev 41871
verify: make `checkentry` a private method
This method is for internal use only.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 06 Mar 2019 12:18:04 +0100] rev 41870
verify: document the `checkentry` method
This method checks various core propertes of a revision. We document inputs, outputs
and the checks performed.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 06 Mar 2019 11:43:21 +0100] rev 41869
verify: add some inline documentation to the top level `verify` method
The goal is to clarify each section goal.