Matt Harbison <matt_harbison@yahoo.com> [Mon, 06 May 2019 22:10:34 -0400] rev 42163
commit: allow --interactive to work again when naming a directory (issue6131)
Yuya Nishihara <yuya@tcha.org> [Fri, 03 May 2019 20:06:03 +0900] rev 42162
parser: fix crash by parsing "()" in keyword argument position
A tree node can be either None or a tuple because x=("group", None) is
reduced to x[1].
Augie Fackler <raf@durin42.com> [Wed, 01 May 2019 14:27:19 -0400] rev 42161
Added signature for changeset 07e479ef7c96
Augie Fackler <raf@durin42.com> [Wed, 01 May 2019 14:27:17 -0400] rev 42160
Added tag 5.0 for changeset 07e479ef7c96
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 25 Apr 2019 19:17:02 +0200] rev 42159
hghave: deal with "rc" release
Without this change, 5.0rc0 is not recognised as 5.0
Pulkit Goyal <pulkit@yandex-team.ru> [Wed, 17 Apr 2019 15:06:41 +0300] rev 42158
narrow: send specs as bundle2 data instead of param (issue5952) (issue6019)
Before this patch, when ACL is involved, narrowspecs are send as bundle2
parameter for narrow:spec bundle2 part. The limitation of bundle2 parts are they
cannot send data larger than 255 bytes. Includes and excludes in narrow are not
limited by size and they can grow over 255 bytes.
This patch introduces a new mandatory bundle2 part and send narrowspecs as data
of that. The new bundle2 part is introduced to keep things cleaner and easy to
distinguish related to backward compatibility.
The part is mandatory because without server's narrowspec, the local ACL narrow
repo won't work.
This patch makes clients compatible with servers which have older versions.
However I left a comment that we should drop the other bundle2 part soon as
that's broken and people should not rely on that.
I named the new bundle2 part 'Narrow:responsespec' because:
1) Capital 'N' to make it mandatory
2) 'Narrow:spec' cannot be used because bundle2 enforces that there should not
be two different parts which resolve to same name when lowercased.
3) reponsespec clears that they are specs which are send as reponse by the
server
While I was here, I renamed `narrowhgacl` section to `narrowacl` as suggested by
idlsoft@ and martinvonz@.
Differential Revision: https://phab.mercurial-scm.org/D6310
Matt Harbison <matt_harbison@yahoo.com> [Fri, 26 Apr 2019 23:52:49 -0400] rev 42157
inno: bump keyring to 18.0.1 to avoid AttributeError (issue6043)
The error seems to be harmless, because it happens after closing the connection.
For whatever reason, this isn't bundled with the Wix installer.
https://github.com/jaraco/keyring/issues/386
https://bitbucket.org/Mekk/mercurial_keyring/issues/63/attributeerror-during-process-finish-with
Pulkit Goyal <pulkit@yandex-team.ru> [Wed, 24 Apr 2019 19:42:43 +0300] rev 42156
context: check file exists before getting data from _wrappedctx
overlayworkingctx class is used to do in-memory merging. The data() function of
that class has logic to look for data() in the wrappedctx if the file data in
cache is empty and if the file is dirty. This assumes that if a file is dirty
and cache has empty data for it, it will exists in the _wrappedctx.
However this assumption can be False in case when we are merging a file which is
empty in destination. In these cases, the backup file 'foo.orig' created by our
internal merge algorithms will be empty, however it won't be present in
_wrappedctx. This case will lead us to error like the one this patch is fixing.
Let's only fallback to getting data from wrappedctx if cache has 'None' as data.
Differential Revision: https://phab.mercurial-scm.org/D6308
Pulkit Goyal <pulkit@yandex-team.ru> [Wed, 24 Apr 2019 19:28:46 +0300] rev 42155
tests: show IMM is broken when merging file empty in destination
When we are doing in-memory merging, and we are merging a file which is empty in
merge destination, it leads to error 'abort: xxx not found in manifest'.
Next patch will fix this error.
Differential Revision: https://phab.mercurial-scm.org/D6307
Antonio Muci <a.mux@inwind.it> [Fri, 19 Apr 2019 02:24:25 +0200] rev 42154
buildrpm: bump bundled Python version to 2.7.16 when building for centos{5,6}
When building rpm packages for centos 5 and 6, we bundle a mercurial-specific
version of Python 2.7 in /opt/python-hg.
This change is analogous to 5e947367606c, and bumps the embedded Python version
from 2.7.14 (released in 2017) to 2.7.16 (latest as of today).
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 21 Apr 2019 08:57:01 -0700] rev 42153
setup: tweak error message for Python 3
We now have beta support for Python 3. In my opinion, it isn't
yet stable enough to allow `pip install Mercurial` to work with
Python 3 out of the box: we don't want people accidentally using
Mercurial with Python 3 just yet.
But I do think we should be more friendly about informing people
of their options.
This commit tweaks the error message that users see when running
setup.py with Python 3. We instruct them about the current level
of Python 3 support, point them at the wiki for more info, and
give them instructions on how to bypass the check.
As part of this, I also changed which version value is printed,
as we were printing a named tuple before.
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 21 Apr 2019 07:21:08 -0700] rev 42152
setup: remove set and dict comprehensions
Yuya observed in a recent review that it is worthwhile to keep
setup.py parseable with Python 2.6 so a useful error message is
seen when attempting to run with Python 2.6.
This commit removes a set and dict comprehension so setup.py
is parseable with Python 2.6.