Now that batch can be used by remotefilelog, the quadratic string
copying this was doing was actually disastrous. In my local testing,
fetching a 56 meg file used to take 3 minutes, and now takes only a
few seconds.
The recommended way to check default value (when None is not as option) is a
token object. Identity testing to integer is less explicit and not guaranteed to
work in all implementations.
When we introduce the develwarning, we did not had an official deprecation API
and infrastructure. We can now officially deprecate the old way with a version
deadline.
When we introduce the develwarning, we did not had an official deprecation API
and infrastructure. We can now officially deprecate the old way with a version
deadline.
When we introduce the develwarning, we did not had an official deprecation API
and infrastructure. We can now officially deprecate the old way with a version
deadline.
With this, test-hghave.t passes on python 3.
Four features fail because mercurial still is not py3 safe:
absimport
cacheable
hardlink
defaultcacerts
But that will be resolved automatically eventually.
Unlike range, dagrange has no inverted range (such as '10:0'). So there should
be no practical reason to keep dagrange as a function that forces its own
ordering.
No performance regression is spotted in contrib/base-revsets.txt.
hg does not yet run with py3, so if you try:
./run-tests.py --local test-check-pyflakes.t
... it will try to run the local hg, which does not work
and thus, hg locate will return no output to stdout (and
stderr is sent to /dev/null).
If you do:
./run-tests.py --with-hg=~/bin/hg test-check-pyflakes.t
Then it should work, if your hg is new enough to have
a locate command (hg0.6 does not have locate).
Allow for a style to only apply to the last N lines (for positive N) or
everything but the first N lines (for negative N) of the section along the
current node. This allows for more subtle grandparent styling.
So from the default:
$ hg log -G ...
o Lorem ipsum dolor sit
:\ amet, consectetur
: : adipiscing elit, sed
: : do eiusmod tempor
: :
o : incididunt ut labore
| : et dolore magna
| : aliqua. Ut enim ad
| : minim veniam, quis
|/
o nostrud exercitation
: ullamco laboris nisi
: ut aliquip ex ea
: commodo consequat.
:
o Duis aute irure dolor
| in reprehenderit in
~ voluptate velit esse
cillum dolore eu
to
$ hg log -G --config "experimental.graphstyle.grandparent=2." ...
o Lorem ipsum dolor sit
|\ amet, consectetur
| | adipiscing elit, sed
. . do eiusmod tempor
. .
o | incididunt ut labore
| | et dolore magna
| | aliqua. Ut enim ad
| | minim veniam, quis
|/
o nostrud exercitation
| ullamco laboris nisi
| ut aliquip ex ea
. commodo consequat.
.
o Duis aute irure dolor
| in reprehenderit in
~ voluptate velit esse
cillum dolore eu
or
$ hg log -G --config "experimental.graphstyle.grandparent=1:" ...
o Lorem ipsum dolor sit
|\ amet, consectetur
| | adipiscing elit, sed
| | do eiusmod tempor
: :
o | incididunt ut labore
| | et dolore magna
| | aliqua. Ut enim ad
| | minim veniam, quis
|/
o nostrud exercitation
| ullamco laboris nisi
| ut aliquip ex ea
| commodo consequat.
:
o Duis aute irure dolor
| in reprehenderit in
~ voluptate velit esse
cillum dolore eu
or
$ hg log -G --config "experimental.graphstyle.grandparent=-2!" ...
o Lorem ipsum dolor sit
|\ amet, consectetur
! ! adipiscing elit, sed
! ! do eiusmod tempor
! !
o | incididunt ut labore
| | et dolore magna
| | aliqua. Ut enim ad
| | minim veniam, quis
|/
o nostrud exercitation
| ullamco laboris nisi
! ut aliquip ex ea
! commodo consequat.
!
o Duis aute irure dolor
| in reprehenderit in
~ voluptate velit esse
cillum dolore eu
On PyPy this version performs reasonably well compared to C version.
Example command is "hg id" which gets faster, depending on details
of your operating system and hard drive (it's bottlenecked on stat mostly)
There is potential for improvements by storing extra as a condensed struct too.
Before this patch, we may or may not load extensions for shell aliases
depending on whether the command is abbreviated or not.
Loading extensions may have useful side effects to shell aliases. For example,
the pager extension does not work for shell aliases.
This patch removes the code checking shell aliases before loading extensions
to give the user a more consistent experience. It may hurt performance for
shell aliases a bit without chg but the correctness seems worth it. It will
also make the behavior consistent with chg since chg will always load all
extensions before running commands.
The 3 classes for items used in crecord (uiheader, uihunk, uihunkline) all have
prevsibling() and nextsibling() methods. The two methods are used to get the
previous/next item of the same type of the same parent element as the current
one: when `a` is a uihunkline instance, a.nextsibling() returns the next line
in this hunk (or None, if `a` is the last line).
There are also two similar methods: previtem() and nextitem(). When called with
constrainlevel=True (the default) they simply returned the result of
prevsibling()/nextsibling(). Only when called with constrainlevel=False they
did something different: they returned previous/next item regardless of its
type (so if `a` is the last line in a hunk, a.nextitem(constrainlevel=False)
could return the next hunk or the next file -- something that is not a line).
Let's simplify this logic and make code call -sibling() methods when only
siblings are needed and -item() methods when any item would do, and then remove
the constrainlevel argument from previtem() and nextitem().
The post-* family of hooks will not run in case a command fails (i.e.
raises an exception). This makes it inconvenient to hook into events
such as doing something in case of a failed push.
We catch all exceptions to run the failure hook. I am not sure if this
is too aggressive, but tests apparently pass.
So far fromlocal recognizes relative imports of the form:
from . import D
from .. import E
It wasn't prepared for recognizing relative imports like:
from ..F import G
The bug was not found so far because all relative imports starting
from the parent was in the list of allowsymbolicimports like:
from ..i18n import
from ..node import
The test output was not updated as the lower section of the test updates
with python3.5, so it might be the case that people have updated the modules
but the test was left as it was. So this patch updates the test output.
The previous patch stopped setting web.cacerts=! to indicate
--insecure.
That left user configs as the only source that could introduce
web.cacerts=!.
The practical impact of this patch is we no longer honor
web.cacerts=! in configs. Instead, we always treat web.cacerts
as a path. The patch is therefore technically BC. However,
since I don't believe web.cacerts=! is documented, it should be
safe to remove. 358b7bec186f (which introduced --insecure) has
no indication that web.cacerts=! is anything but an implementation
detail, reinforcing my belief it can be removed without major
debate.
Consumers needing to know if --insecure was used have already
transitioned to using ui.insecureconnections. The previous
patch removed the last meaningful consumer looking for
web.cacerts=!.
Until now, sslkwargs may set web.cacerts=! to indicate
that system certs could not be found. This is really
obtuse because sslkwargs effectively sets state on a global
object which bypasses wrapsocket() and is later consulted
by validator.__call__. This is madness.
This patch introduces an attribute on the wrapped socket
instance indicating whether system CAs were loaded. We
can set this directly inside wrapsocket() because that
function knows everything that sslkwargs() does - and more.
With this attribute set on the socket, we refactor
validator.__call__ to use it.
Since we no longer have a need for setting web.cacerts=!
in sslkwargs, we remove that.
I think the new logic is much easier to understand and will
enable behavior to be changed more easily.
Right now, web.cacerts=! means one of two things:
1) Use of --insecure
2) No CAs could be found and were loaded (see sslkwargs)
This isn't very obvious and makes changing behavior of these
different scenarios independent of the other impossible.
This patch changes the validator code to explicit handle the
case of --insecure being used.
As the inline comment indicates, there is room to possibly change
messaging and logic here. For now, we are backwards compatible.
The end result of this function is the same. We now have a more
explicit return branch.
We still keep the old code looking at web.cacerts=! a few lines
below because we're still setting web.cacerts=! and need to react
to the variable. This will be removed in an upcoming patch.
Currently, when --insecure is used we set web.cacerts=! and
socket validation takes this value into account. web.cacerts=!
is not documented AFAICT and is purely an internal implementation
detail.
Let's be more explicit about what is going on by introducing a
dedicated variable outside of the config values to track that
--insecure is used.
The ways in which this code can interact with socket wrapping
and validation later are mind numbing. This patch helps make it
even more clear.
The end behavior should be identical.
Before, the return of _defaultcacerts() was 1 of 3 types. This was
difficult to read. Make it return a path or None.
We had to update hghave.py in the same patch because it was also
looking at this internal function. I wasted dozens of minutes
trying to figure out why tests were failing until I found the
code in hghave.py...
