Mon, 20 May 2019 07:11:06 +0200 test: update test for expected test output stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 May 2019 07:11:06 +0200] rev 42165
test: update test for expected test output In 1fac9b931d46 as new test session was introduced. It did not take in account some part that only ran for pure. The test is now fixed.
Wed, 08 May 2019 16:09:50 -0400 sslutil: fsencode path returned by certifi (issue6132) stable
Augie Fackler <augie@google.com> [Wed, 08 May 2019 16:09:50 -0400] rev 42164
sslutil: fsencode path returned by certifi (issue6132) By inspection, this is the only codepath that could be returning a string instead of a bytes on Python 3.
Mon, 06 May 2019 22:10:34 -0400 commit: allow --interactive to work again when naming a directory (issue6131) stable
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)
Fri, 03 May 2019 20:06:03 +0900 parser: fix crash by parsing "()" in keyword argument position stable
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].
Wed, 01 May 2019 14:27:19 -0400 Added signature for changeset 07e479ef7c96 stable
Augie Fackler <raf@durin42.com> [Wed, 01 May 2019 14:27:19 -0400] rev 42161
Added signature for changeset 07e479ef7c96
Wed, 01 May 2019 14:27:17 -0400 Added tag 5.0 for changeset 07e479ef7c96 stable
Augie Fackler <raf@durin42.com> [Wed, 01 May 2019 14:27:17 -0400] rev 42160
Added tag 5.0 for changeset 07e479ef7c96
Thu, 25 Apr 2019 19:17:02 +0200 hghave: deal with "rc" release stable 5.0
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
Wed, 17 Apr 2019 15:06:41 +0300 narrow: send specs as bundle2 data instead of param (issue5952) (issue6019) stable
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
Fri, 26 Apr 2019 23:52:49 -0400 inno: bump keyring to 18.0.1 to avoid AttributeError (issue6043) stable
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
Wed, 24 Apr 2019 19:42:43 +0300 context: check file exists before getting data from _wrappedctx stable
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
Wed, 24 Apr 2019 19:28:46 +0300 tests: show IMM is broken when merging file empty in destination stable
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
Fri, 19 Apr 2019 02:24:25 +0200 buildrpm: bump bundled Python version to 2.7.16 when building for centos{5,6} stable
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).
Sun, 21 Apr 2019 08:57:01 -0700 setup: tweak error message for Python 3 stable
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.
Sun, 21 Apr 2019 07:21:08 -0700 setup: remove set and dict comprehensions stable
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.
Fri, 19 Apr 2019 23:13:28 +0300 branchcache: don't verify all nodes while writing stable
Pulkit Goyal <pulkit@yandex-team.ru> [Fri, 19 Apr 2019 23:13:28 +0300] rev 42151
branchcache: don't verify all nodes while writing nodes are verified either when they are added or used. In case of commits. we will load the whole branchmap, only verify nodes for the branch on which we are committing and then we write. However before this patch, writing the branchmap was validating all the nodes whereas it should not. This patch fixes that. Differential Revision: https://phab.mercurial-scm.org/D6290
Sat, 20 Apr 2019 07:29:07 -0700 setup: properly package distutils in py2exe virtualenv builds stable
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 20 Apr 2019 07:29:07 -0700] rev 42150
setup: properly package distutils in py2exe virtualenv builds Our in-repo py2exe packaging code uses virtualenvs for managing dependencies. An advantage of this is that packaging is more deterministic and reproducible. Without virtualenvs, we need to install packages in the system Python install. Packages installed by other consumers of the system Python could leak into the Mercurial package. A regression from this change was that py2exe packages contained the virtualenv's hacked distutils modules instead of the original distutils modules. (virtualenv installs a hacked distutils module because distutils uses relative path lookups that fail when running from a virtualenv.) This commit introduces a workaround so py2exe packaging uses the original distutils modules when running from a virtualenv. With this change, `import distutils` no longer fails from py2exe builds produced from a virtualenv. This fixes the regression. Furthermore, we now include all distutils modules. Before, py2exe's module finding would only find modules there were explicitly referenced in code. So, we now package a complete copy of distutils instead of a partial one. This is even better than before. # no-check-commit foo_bar function name
Wed, 17 Apr 2019 14:10:02 -0400 merge: forgot to pull before release stable
Augie Fackler <augie@google.com> [Wed, 17 Apr 2019 14:10:02 -0400] rev 42149
merge: forgot to pull before release These two changes should be part of 5.0, but we are fine leaving them out of the RC.
Tue, 16 Apr 2019 15:50:20 +0200 debugdiscovery: include the number of heads in all sets
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 16 Apr 2019 15:50:20 +0200] rev 42148
debugdiscovery: include the number of heads in all sets We already displayed information about heads of the common set that are either local or remote heads. We now also do so for heads of the common set that are both local and remote heads too. This is useful because various step in the set discovery algorithm have head specific optimizations.
Wed, 17 Apr 2019 00:37:00 +0200 recover: add a --[no-]verify flag
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 17 Apr 2019 00:37:00 +0200] rev 42147
recover: add a --[no-]verify flag For trivial cases, the cost of the verify run after `hg recover` is getting in the way. In addition for very large repositories, the cost is simply too high to be paid, making `hg recover` an unusable commands. We introduce a --verify flag, set by default. If is automatically associated with a --no-verify flag that one can use to skip the verify step. We might consider changing the default behavior in the future. However this is out of scope for this series.
Wed, 17 Apr 2019 13:56:10 -0400 Added signature for changeset 4a8d9ed86475 stable
Augie Fackler <raf@durin42.com> [Wed, 17 Apr 2019 13:56:10 -0400] rev 42146
Added signature for changeset 4a8d9ed86475
Wed, 17 Apr 2019 13:56:08 -0400 Added tag 5.0rc0 for changeset 4a8d9ed86475 stable
Augie Fackler <raf@durin42.com> [Wed, 17 Apr 2019 13:56:08 -0400] rev 42145
Added tag 5.0rc0 for changeset 4a8d9ed86475
Wed, 17 Apr 2019 13:41:18 -0400 merge: default into stable for release candidate stable 5.0rc0
Augie Fackler <augie@google.com> [Wed, 17 Apr 2019 13:41:18 -0400] rev 42144
merge: default into stable for release candidate
Tue, 02 Apr 2019 19:48:31 +0200 bundle2: handle compression in _forwardchunks
Joerg Sonnenberger <joerg@bec.de> [Tue, 02 Apr 2019 19:48:31 +0200] rev 42143
bundle2: handle compression in _forwardchunks _forwardchunks is used to compensate for getbundle protocol deficits. Since it transparently decodes the payload, it also needs to remove the corresponding compression parameter in case the server decides to send one. This the wire protocol part of issue 5990. Differential Revision: https://phab.mercurial-scm.org/D6182
Wed, 27 Dec 2017 22:05:20 -0800 changelog: parse copy metadata if available in extras
Martin von Zweigbergk <martinvonz@google.com> [Wed, 27 Dec 2017 22:05:20 -0800] rev 42142
changelog: parse copy metadata if available in extras This lets read back the copy metadata we just started writing. There are still many places left to teach about getting the copy information from the changeset, but we have enough ({file_copies}, specifically) that we can add it now and have some test coverage of it. Differential Revision: https://phab.mercurial-scm.org/D6186
Wed, 27 Dec 2017 19:49:36 -0800 copies: add config option for writing copy metadata to file and/or changset
Martin von Zweigbergk <martinvonz@google.com> [Wed, 27 Dec 2017 19:49:36 -0800] rev 42141
copies: add config option for writing copy metadata to file and/or changset This introduces a config option that lets you choose to write copy metadata to the changeset extras instead of to filelog. There's also an option to write it to both places. I imagine that may possibly be useful when transitioning an existing repo. The copy metadata is stored as two fields in extras: one for copies since p1 and one for copies since p2. I may need to add more information later in order to make copy tracing faster. Specifically, I'm thinking out recording which files were added or removed so that copies._chaincopies() doesn't have to look at the manifest for that. But that would just be an optimization and that can be added once we know if it's necessary. I have also considered saving space by using replacing the destination file path by an index into the "files" list, but that can also be changed later (but before the feature is ready to release). Differential Revision: https://phab.mercurial-scm.org/D6183
Thu, 04 Apr 2019 13:46:49 +0200 revsetbenchmark: add some simpler revset for heads and roots
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 04 Apr 2019 13:46:49 +0200] rev 42140
revsetbenchmark: add some simpler revset for heads and roots This revset might leverage compiled code in the future so lets start to track them.
Fri, 12 Apr 2019 16:25:59 +0200 repoview: flag `server.view` as experimental
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 12 Apr 2019 16:25:59 +0200] rev 42139
repoview: flag `server.view` as experimental Ideally, the non-experimental version of `experimental.extra-filter-revs` will cover the use case for `server.view=immutable` well enough than having to have this dedicated configuration. Since `server.view` is not part of any release, I would prefer to have it marked as experimental to avoid having it to support it for ever.
Fri, 12 Apr 2019 15:41:32 +0200 repoview: move subsettable in a dedicated module
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 12 Apr 2019 15:41:32 +0200] rev 42138
repoview: move subsettable in a dedicated module The dictionary got moved in `branchmap` to avoid import cycle. However, we are about to needs it in repoview too. So we introduce a now module to define that that mapping.
Fri, 01 Feb 2019 15:51:02 +0100 upgrade: support upgrade to/from zstd storage (issue6088)
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 01 Feb 2019 15:51:02 +0100] rev 42137
upgrade: support upgrade to/from zstd storage (issue6088) Now that we have an official config option for a shiny format improvement, we better make it simple to migrate to/from it.
Wed, 27 Mar 2019 18:27:03 +0100 compression: introduce an official `zstd-revlog` requirement
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 27 Mar 2019 18:27:03 +0100] rev 42136
compression: introduce an official `zstd-revlog` requirement This requirement supersedes `exp-compression-zstd`. However, we keep support for the old requirement. Strictly speaking, we do not need to add a new requirement, there are no logic change making "new" repo incompatible with mercurial client using a version that support `exp-compression-zstd`. The choice to introduce a new requirement is motivated by the following: * The previous requirement was explicitly "experimental". Using it by default could confuse users. * adding support for a hypothetical third compression engine will requires new code, and will comes with its own requirement tool. * We won't use it as the default for a while since I do not think we support zstd on all platform. I can imagine we'll gain another (unrelated but on my default) requirement by the time we turn this zstd by default.
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip