_funcregistrarbase differs from funcregistrar in points below:
- every code paths should use same class derived from
_funcregistrarbase to register functions in a same category
funcregistrar expects (3rd party) extensions to use (a class
derived from) delayregistrar.
- actual extra setup should be executed in another function
For example, marking revset predicate as "safe" is executed in a
class derived from _funcregistrarbase, but putting name of "safe"
predicate into safesymbols is executed in another function for it.
funcregistrar expects derived classes to do so.
New class is named as module private one, because code paths, which
register functions, should use not it directly but one derived from
it.
This patch makes loading extra information from extension module at
dispatching extensible. Factoring 'loadcmdtable()' into commands.py is
a part of generalization of loading extra information.
This extensibility assumes registration of new function like below,
for example:
- revset predicate
- fileset predicate
- template keyword
- template filter
- template function
- internal merge tool
- web command
This patch requires not loader function itself but container module
and the name of it, because listing loader function directly up
implies actual loading module of it, even if it isn't used at runtime
(for example, extensions don't always define revset predicate)
The old native head revs logic would iterate over every node, starting from 0,
and check if every node was filtered (by testing it against the filteredrevs
python set). On large repos with hundreds of thousands of commits, this could
take 150ms.
This new logic iterates over the nodes in reverse order, and skips the filtered
check if we've seen an unfiltered child of the node. This saves approximately a
bagillion filteredrevs set checks, which shaves the time down from 150ms to
20ms during every branch cache write.
Before this patch, destupdate() returns the tipmost (descendant)
branch head regardless of closed or not. But updating to closed branch
head isn't reasonable for ordinary workflow, because:
- "hg heads" doesn't show closed heads (= updated parent itself) by
default
- subsequent committing on it re-opens closed branch
even if inactivation of closed head is needed, update destination
isn't it, because it should be merged into to another branch in
such case.
This patch chooses non-closed descendant branch head as default update
destination at first. If all descendant branch heads are closed,
destupdate() returns the tipmost closed branch head.
For simplicity, this patch chooses adding _destupdatebranchfallback()
instead largely changing _destupdatebranch().
This patch changes not only normal lookup code path, but also the "no
default branch" code path, for consistency.
To describe the bug this fix is addressing, one can do
``$ hg status -T "{label('red', path)}\n" --color=debug``
and observe that the label is not applied before my fix and applied with it.
The walker knows when an edge leads to a direct parent, a grandparent (skipping
revisions not part of the revset) and parents that are missing altogether
(neither it nor a grandparent is in the revset). Add this information to the
parents sequence yielded.
Instead of the mapping hack introduced by d4686e0c15c9, this patch changes the
way how a label symbol is evaluated. This is still hackish, but should be more
predictable in that it doesn't depend on the known color effects.
This change is intended to eliminate the reference to color._effects so that
color.templatelabel() can be merged with templater.label().
Testing 'node in repo' requires constructing a changectx, which is a little
expensive. Testing 'repo.changelog.hasnode(node)' is notably faster. This
saves 10-20ms off of every command, when testing a few thousand nodes from the
branch cache.
I considered changing the implementation of localrepository.__contains__ so
every place would benefit from the change, but since
localrepository.__contains__ uses changectx to check if the commit exists, it
means it supports a wider range of possible inputs (like revs, hashes, '.',
etc), so it seemed unnecessarily risky.
The progress callback is replaced by one for manifests after changelog
processing is done, but let's not depend on manifests replacing the
value and instead explicitly clear it.
The "prog" class cg1unpacker.apply() has the unit set to
"chunks". This is not correct for files, where the file itself is the
unit. The unit is not usually printed, which is probably why this has
not been fixed yet. It can be show with e.g. "--config
progress.format='topic number unit'".
The progress callback for manifests is cleared outside of
_unpackmanifests(), which means it will remain in effect while pulling
subdirectory manifests when using treemanifests. Since the total
number of revisions used for the progress is the number of changesets,
the total number of treemanifest revisions is usually larger than
that. One effect of this is that the ETA is negative. It's hard to
estimate the number of subdirectory revisions, so let's just exclude
them from progress for now.
Before this, "{noniterable % template}" raised an exception. This tries to
provide a better indication for the common case, where a left-hand-side
expression is a keyword.
A function argument may be an integer. In this case, it isn't necessary to
convert a value to string and back to integer.
Because an argument may be an arbitrary object (e.g. date tuple), TypeError
should be caught as well.
If a key is constructed from a template expression, it may be a generator.
In that case, a key have to be stringified.
A dictarg should never be a generator, but this patch also changes it to
call evalfuncarg() for consistency.
There are race conditions between clients performing a shared clone
to pooled storage:
1) Clients race to create the new shared repo in the pool directory
2) 1 client is seeding the repo in the pool directory and another goes
to share it before it is fully cloned
We prevent these race conditions by obtaining a lock in the pool
directory that is derived from the name of the repo we will be
accessing.
To test this, a simple generic "lockdelay" extension has been added.
The extension inserts an optional, configurable delay before or after
lock acquisition. In the test, we delay 2 seconds after lock acquisition
in the first process and 1 second before lock acquisition in the 2nd
process. This means the first process has 1s to obtain the lock. There
is a race condition here. If we encounter it in the wild, we could
change the dummy extension to wait on the lock file to appear instead
of relying on timing. But that's more complicated. Let's see what
happens first.
Before this patch, deprecated options below are used in synopsis of
command help, even though they aren't listed up as available options
by default. These might confuse readers.
- -n (no-op, now) of strip
- -a/--active of branches
- -f/--force of merge
This is the simplest workaround for the issue of the ordering of revset, which
is that the expression "x or y" takes over the ordering specified by the input
set (or the left-hand-side expression.) For example, the following expression
A & (x | y)
will be evaluated as if
(A & x) | (A & y)
That's wrong because revset has ordering. I'm going to fix this problem in
the revset module, but that wouldn't fit to stable. So, this patch just works
around the common log cases.
Since this change might have some impact on performance, it is enabled only
if the expression built from log options has ' or ' operation.
Mozilla is seeing an issue with demand importing of _imp
failing in pkg_resources/__init__.py:fixup_namespace_packages.
It strangely only reproduces when using a modern version of
setuptools/pip in certain scenarios. Adding _imp to the demand import
ignore list seems to make the problem go away.
The unionrepository have to do some special magic to handle linkrev of the
unioned filerev and manifestrev. That logic was done from a repoview and
obsolescence marker affecting bundled changeset could lead to a crash. We now
ensure we operate on unfiltered repository.
The bundlerepository have to do some special magic to handle linkrev of the
bundled manifest. That logic was done from a repoview and obsolescence marker
affecting bundled changeset could lead to a crash. We now ensure we operate on
unfiltered repository.
The bundlerepository have to do some special magic to handle linkrev of the
bundlerepo filerev. That logic was done from a repoview and obsolescence marker
affecting bundled changeset could lead to a crash. We now ensure we operate on
unfiltered repository.
During merge, added (from one perspective) file can be reported as "modified".
To work around that, revert was testing if modified file were present in the
parent manifest and marking them as "added" in this case. However, we should be
checking against the target revision manifest instead. Otherwise see file as
"newly added" even if they exist in the target revision.
That revert behavior regressed in 3657ae7519b7.
Adjust the examples (prefix and hostfingerprints) in help/config.txt
https://hg.intevation.de/ is now served with a new certificate that is signed
by a commercial CA, so all nearly all browsers will accept it automatically.
Listing both names, hg.intevation.de and hg.intevation.org, in the section
[hostfingerprints] allows using both without configuring web.cacerts and
without changing existing https URLs in the [paths] section.
The "hg purge" alias as currently described in "hgrc.5" only works, if
the caller's current working directory is identical to the repository's
root directory.
This patch slightly modifies the example by adding an empty pattern as a
file argument to the "hg status" command, thus forcing this command to
list the affected files relative to the current directory.
Since we've dropped a str cast at write() by 7dbd3db608c5, ui.prompt() should
convert default to '' if it is None. Otherwise, write() would fail with
"TypeError: object of type 'NoneType' has no len()".
This patch includes the tests for both interactive and non-interactive cases
because "ui.askusername" was never tested.
Internal _matchfiles() function can take bunch of arguments, which would
lead to a maximum recursion depth error. This patch avoids the excessive
stack use by flattening 'list' nodes beforehand.
Since getlist() no longer takes a nested 'list' nodes, _parsealiasdecl()
also needs to flatten argument list, "aliasname($1, $2, ...)".
This backs out changeset fd794e885a9e9.
There are some extra fields that absolutely should not be preserved, like the
convert_revision field introduced by the convert and hgsubversion extensions.
The problem with extensions blacklisting certain extra fields is that they
might not be enabled at the time the amend is performed.
In the long run we probably want separately marked transferable and
non-transferable extra fields, but for now restore the old Mercurial 3.6
behavior.
On Solaris, recvmsg() is provided by libsocket.so. We could try hard to look
for the library which provides 'recvmsg' symbol, but it would make little sense
now since recvfds() won't work anyway on Solaris. So this patch just disables
_recvmsg() on such platforms.
Thanks to FUJIWARA Katsunori for spotting this problem.
It appears that Solaris doesn't provide CMSG_LEN(), msg_control, etc. As
recvfds() is only necessary for chg, this patch just drops it if CMSG_LEN
isn't defined, which is the same workaround as Python 3.x.
https://hg.python.org/cpython/rev/c64216addd7f#l7.33
In 0413f674179e (verify: move file cross checking to its own function,
2016-01-05), "mflinkrevs = None" was moved into function, so the
reference was cleared there, but the calling function now held on to
the variable. The point of clearing it was presumably to free up
memory, so let's move the clearing to the calling function where it
makes a difference. Also change "mflinkrevs = None" to "del
mflinkrevs", since the comment about scope now surely is obsolete.
Before this patch, text blocks changed in this patch are shown as just
continuous text blocks like below in HTML format.
Global configuration like the username setting is typically put into:
%USERPROFILE%\mercurial.ini
$HOME/.hgrc
This patch itemizes these text blocks to increase readability in HTML
format.
Global configuration like the username setting is typically put into:
- %USERPROFILE%\mercurial.ini (on Windows)
- $HOME/.hgrc (on Unix, Plan9)
Like as other platform sensitive container-ed text blocks, this patch
also adds explicit "on PLATFORM" information to each items for
readability in HTML format, even though output of "hg help config" on
command line seems a little redundant. For example, on Unix:
Global configuration like the username setting is typically put into:
- "$HOME/.hgrc" (on Unix, Plan9)
Because "backout --merge" have to make a commit before merging, it doesn't
work with --no-commit. We could change "backout --merge" to make a merge
commit automatically, and --no-commit to bypass a merge commit, but that
change would be undesirable because:
a) it's hard to fix bad merges in general
b) two commits would be created with the same --message
So, this patch simply disables "--merge --no-commit".
In b89de5ee5b31 (changegroup: don't support versions 01 and 02 with
treemanifests, 2016-01-19), I stopped supporting use of cg1 and cg2
with treemanifest repos. What I had not considered was that it's
perfectly safe to pull *to* a treemanifest repo using any changegroup
version. As reported in issue5066, I therefore broke pull from old
repos into a treemanifest repo. It was not covered by the test case,
because that pulled from a local repo while enabling treemanifests,
which enabled treemanifests on the source repo as well. After
switching to pulling via HTTP, it breaks.
Fix by splitting up changegroup.supportedversions() into
supportedincomingversions() and supportedoutgoingversions().
In my patch series ending with rev c3f2eede6938 I switched most change/delete
conflicts to be handled at the resolve layer. .hgsubstate was the one file that
we weren't able to handle, so we kept the old code path around for it.
The old code path added .hgsubstate to one of the other lists as the user
specifies, including possibly the 'g' list.
Now since we did this check after converting the actions from being keyed by
file to being keyed by action type, there was nothing that actually removed
.hgsubstate from the 'cd' or 'dc' lists. This meant that the file would
eventually make its way into the 'mergeactions' list, now freshly augmented
with 'cd' and 'dc' actions.
We call subrepo.submerge for both 'g' actions and merge actions.
This means that if the resolution to an .hgsubstate change/delete conflict was
to add it to the 'g' list, subrepo.submerge would be called twice. It turns out
that this doesn't cause any adverse effects on Linux due to caching, but
apparently breaks on other operating systems including Windows.
The fix here moves this to before we convert the actions over. This ensures
that it .hgsubstate doesn't make its way into multiple lists.
The real fix here is going to be:
(1) move .hgsubstate conflict resolution into the resolve layer, and
(2) use a real data structure for the actions rather than shuffling data around
between lists and dictionaries: we need a hash (or prefix-based) index by
file and a list index by action type.
There's a very tiny behavior change here: collision detection on
case-insensitive systems will happen after this is resolved, not before. I think
this is the right change -- .hgsubstate could theoretically collide with other
files -- but in any case it makes no practical difference.
Thanks to Yuya Nishihara for investigating this.
