- Aug 02, 2016
-
-
Pierre-Yves David authored
This is an old config that predate bundle2 on by default. This should have been remove after Mercurail 3.6 got released.
-
- Aug 01, 2016
-
-
Augie Fackler authored
-
durin42 authored
-
durin42 authored
-
- Jul 31, 2016
-
-
Katsunori FUJIWARA authored
Before this patch, certificate example is formatted just as normal text.
-
Katsunori FUJIWARA authored
-
Katsunori FUJIWARA authored
List of available keywords is well formatted as a list of fields in doc string, but is formatted as just normal text in online help output.
-
Katsunori FUJIWARA authored
xgettext expects both "_()" and (a part of) text to be placed at just next line of "i18n:" comment.
-
Katsunori FUJIWARA authored
In this case, column positioning isn't needed for i18n, too. Maybe, check-code warning "missing _() in ui message" caused this useless _() invocation in 92d37fb3f1aa.
-
Katsunori FUJIWARA authored
-
Katsunori FUJIWARA authored
-
- Jul 30, 2016
-
-
Katsunori FUJIWARA authored
Before this patch, importing C module on Windows environment causes infinite recursion call, if py2exe is used with -b2 option. At importing C module "a.b", extra hooking by zipextimporter of py2exe causes: 0. assumption before accessing "b" of "a": - built-in module object is created for "a", (= "a" is actually imported) - _demandmod is created for "a.b" as a proxy object, and (= "a.b" is not yet imported) - an attribute "b" of "a" is initialized by the latter 1. invocation of __import__ via _hgextimport() in _demandmod._load() for "a.b" implies _demandimport() for "a.b" This is unintentional, because _demandmod might be returned by _hgextimport() instead of built-in module object. 2. _demandimport() at (1) is invoked with not context of "a", but context of zipextimporter Just after invocation of _hgextimport() in _demandimport(), an attribute "b" of the built-in module object for "a" is still bound to the proxy object for "a.b", because context of "a" isn't updated by actual importing "a.b". even though the built-in module object for "a.b" already appears in sys.modules. Therefore, chainmodules() returns _demandmod for "a.b", which is gotten from the attribute "b" of "a". 3. processfromitem() on "a.b" causes _demandmod._load() for "a.b" again _demandimport() takes context of "a" in this case. Therefore, attributes below are bound to built-in module object for "a.b", as expected: - "b" of built-in module object for "a" - _module of _demandmod for "a.b" 4. but _demandimport() invoked at (1) returns _demandmod object because _demandimport() just returns the object returned by chainmodules() at (3) above. 5. then, _demandmod._load() causes infinite recursion call _demandimport() returns _demandmod for "a.b", and it is "self" at _demandmod._load(). To avoid infinite recursion at actual module importing, this patch uses self._module, if _hgextimport() returns _demandmod itself. If _demandmod._module isn't yet bound at this point, execution should be aborted, because actual importing failed. In this patch, _demandmod._module is examined not on _demandimport() side, but on _demandmod._load() side, because: - the former has some exit points - only the latter uses _hgextimport(), except for _demandimport() BTW, this issue occurs only in the code path for non .py/.pyc files in zipextimporter (strictly speaking, in _memimporter) of py2exe. Even if zipextimporter is enabled, .py/.pyc files are handled by zipimporter, and it doesn't imply unintentional _demandimport() at invocation of __import__ via _hgextimport().
-
- Jul 28, 2016
-
-
Pierre-Yves David authored
People running packages related code probably do care about the content of this directory. In particular this shound fix the rpm builder process.
-
Pierre-Yves David authored
Removing the 'packages' directory makes nightly builder life much harder.
-
- Jul 29, 2016
-
-
Kim Randell authored
Some draconian IT setups lock accounts after a small number of incorrect password attempts. Mercurial's implementation of the urllib2 authentication was causing 5 retry attempts with the same credentials, without prompting the user. The code was attempting to check whether the authorization token had changed, but unfortunately was reading the misleading 'headers' member of the request instead of using the 'get_header' accessor. Modelled on fix for Python issue 8797: https://bugs.python.org/issue8797 https://hg.python.org/cpython/rev/30e8a8f22a2a
-
- Jul 27, 2016
-
-
Matt Mackall authored
The "normal" ISO date/time includes a T between date and time. It also allows dropping the colons and seconds from the timespec. Add new patterns for these forms as well as tests.
-
Matt Mackall authored
-
Matt Mackall authored
We want to be able to accept ISO 8601 style timezones that don't include a space separator, so we change the timezone parsing function to accept a full date string and return both the offset and the non-timezone portion.
-
- Jul 28, 2016
-
-
Gregory Szorc authored
We do this in the rest of the file. This bad line was introduced in 3fde328d0913.
-
- Jul 27, 2016
-
-
Christian Ebert authored
f0564402d059 causes a fatal AttributeError if kwdemo is run outside a repo because in the temporary repo creation repo is None and therefore cannot have a baseui attribute. In this case fall back to using ui. Add test case.
-
Hannes Oldenburg authored
Previously a subrepository "sub" would cause no warnings to be issued for a file "subnot/a", if it's not present in the corresponding changeset when calling: hg cat subnot/a
-
- Jul 25, 2016
-
-
Gábor Stefanik authored
Make life easier for extension writers.
-
Gregory Szorc authored
SSLContext.get_ca_certs() can raise "ssl.SSLError: unknown error (_ssl.c:636)" on Windows. See https://bugs.python.org/issue20916 for more info. We add a try..except that swallows the exception to work around this bug. If we encounter the bug, we won't print a warning message about attempting to load CA certificates. This is unfortunate. But there appears to be little we can do :/
-
- Jul 18, 2016
-
-
Matt Mackall authored
The existing code (a) assumed path would be specified in encoding.encoding and (b) assumed unicode() objects wouldn't cause other parts of Mercurial to blow up. Both are dangerous assumptions. Since we don't know the encoding of path and can't pass non-ASCII through docstrings, just escape the path and drop the early _(). Will have to suffice until we can teach docstrings to handle UTF-8b escaping. This has the side-effect that the line containing the path is now variable by the time it reaches _() and thus can't be translated.
-
- Jul 21, 2016
-
-
Kostia Balytskyi authored
In 1e4512eac59e, I introduced a new bug: when a symlink points to a folder in commit A and to another folder in commit B, while updating from A to B, Mercurial will try to use removedir on this symlink, which will fail. This is a very bad bug, since it basically renders symlinks to folders unusable in repos. Added test case fails without a fix and passes with it.
-
- Jul 25, 2016
-
-
Anton Shestakov authored
-
Anton Shestakov authored
-
Anton Shestakov authored
-
Anton Shestakov authored
-
- Jul 22, 2016
-
-
Yuya Nishihara authored
Since the default joinfmt() can't process a dict of multiple keywords, we need a dedicated joinfmt for showparents(). Unlike revset(), parents are formatted as '{rev}:{node|formatnode}' by default. We copy the default formatting just like showextras() and showfilecopies() do.
-
Yuya Nishihara authored
It's been broken since e4609ec959f8, which made makemap() return a dict of multiple keywords. Because the default joinfmt() randomly picks one item from a dict, we have to make revset() select d[name] explicitly.
-
Hannes Oldenburg authored
Previously a subrepository "sub" would cause no warnings to be issued for a file "subnot/a" if it is not removed when calling: hg remove -S "subnot/a"
-
- Jul 20, 2016
-
-
Matt Mackall authored
-
- Jul 19, 2016
-
-
Wagner Bruna authored
-
- Jul 20, 2016
-
-
Gregory Szorc authored
There are various causes for the inability to negotiate common SSL/TLS protocol between client and server. Previously, we had a single, not very actionable warning message for all of them. As people encountered TLS 1.0 servers in real life, it was quickly obvious that the existing messaging was inadequate to help users rectify the situation. This patch makes the warning messages much more verbose in hopes of making them more actionable while simultaneously encouraging users and servers to adopt better security practices. This messaging flirts with the anti-pattern of "never blame the user" by signaling out poorly-configured servers. But if we're going to disallow TLS 1.0 by default, I think we need to say *something* or people are just going to blame Mercurial for not being able to connect. The messaging tries to exonerate Mercurial from being the at fault party by pointing out the server is the entity that doesn't support proper security (when appropriate, of course).
-
Gregory Szorc authored
This will be used in a subsequent patch to improve messaging.
-
Gregory Szorc authored
--insecure is our psuedo-supported footgun for disabling connection security. The flag already disables CA verification. I think allowing the use of TLS 1.0 when specified is appropriate.
-
Gregory Szorc authored
TIL that ui instances for remote/peer repos don't automagically inherit config options from .hg/hgrc files. This patch makes remote ui instances inherit options from the [hostsecurity] section. We were already inheriting options from [hostfingerprints] and [auth]. So adding [hostsecurity] to the list seems appropriate.
-
- Jul 18, 2016
-
-
Mads Kiilerich authored
The code used self._rbcnamescount as if it was the length of self._names ... but actually it is just the number of good entries on disk. This caused the cache to be populated inefficiently. In some cases very inefficiently. Instead of checking the length before lookup, just try a lookup in self._names - that is also in most cases faster. Comments and debug messages are tweaked to help understanding the issue and the fix.
-