Mon, 15 Apr 2019 15:28:41 -0700 tests: delete unused function in test-rename-merge2.t
Martin von Zweigbergk <martinvonz@google.com> [Mon, 15 Apr 2019 15:28:41 -0700] rev 42152
tests: delete unused function in test-rename-merge2.t Differential Revision: https://phab.mercurial-scm.org/D6253
Sun, 14 Apr 2019 13:46:40 -0700 tests: make merge conflicts explicit in `hg annotate` tests
Martin von Zweigbergk <martinvonz@google.com> [Sun, 14 Apr 2019 13:46:40 -0700] rev 42151
tests: make merge conflicts explicit in `hg annotate` tests We were using `true` as merge tool. I think it makes the test easier to understand if we make the conflicts explcit. It also papered over a conflict that shouldn't have been a conflict (just a bug in copy tracing). I've marked that "BROKEN". Differential Revision: https://phab.mercurial-scm.org/D6252
Thu, 18 Apr 2019 03:05:42 +0530 narrow: make warning about possibly dirty files respect ui.relative-paths
Martin von Zweigbergk <martinvonz@google.com> [Thu, 18 Apr 2019 03:05:42 +0530] rev 42150
narrow: make warning about possibly dirty files respect ui.relative-paths Differential Revision: https://phab.mercurial-scm.org/D6264
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.
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 42148
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 42147
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 42146
merge: default into stable for release candidate
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 42145
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 42144
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.
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.
Tue, 16 Apr 2019 15:10:16 +0200 compression: only declare revlog support for available engine
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 16 Apr 2019 15:10:16 +0200] rev 42135
compression: only declare revlog support for available engine Even if we know that an engine support revlog compression, the Mercurial process still won't support it if the compression engine is not available.
Mon, 15 Apr 2019 19:21:41 +0300 branchcache: lazily validate nodes in iteritems()
Pulkit Goyal <pulkit@yandex-team.ru> [Mon, 15 Apr 2019 19:21:41 +0300] rev 42134
branchcache: lazily validate nodes in iteritems() This saves ~0.30 sec on creating a new branch on our internal repo. Differential Revision: https://phab.mercurial-scm.org/D6236
Tue, 16 Apr 2019 15:01:33 +0300 branchcache: only iterate over branches which needs to be verified
Pulkit Goyal <pulkit@yandex-team.ru> [Tue, 16 Apr 2019 15:01:33 +0300] rev 42133
branchcache: only iterate over branches which needs to be verified Otherwise we loop over all the branches and call _verifybranch() even if not required. Differential Revision: https://phab.mercurial-scm.org/D6240
Tue, 16 Apr 2019 14:48:48 +0300 branchcache: fix the docstring of _verifybranch()
Pulkit Goyal <pulkit@yandex-team.ru> [Tue, 16 Apr 2019 14:48:48 +0300] rev 42132
branchcache: fix the docstring of _verifybranch() Initially the function was designed to support verifying all branches but later I decided to have a separate function. I forget to remove the doc related to that. Thanks to Yuya for spotting this in review. Differential Revision: https://phab.mercurial-scm.org/D6239
Tue, 16 Apr 2019 14:39:14 +0300 branchcache: don't verify while creating a copy
Pulkit Goyal <pulkit@yandex-team.ru> [Tue, 16 Apr 2019 14:39:14 +0300] rev 42131
branchcache: don't verify while creating a copy The copy will not be mark as verified, so there is no need to verify nodes. Thanks to Yuya who spotted this while reviewing. Differential Revision: https://phab.mercurial-scm.org/D6238
Fri, 05 Apr 2019 14:35:33 +0200 pull: improved message issued in case of failed update
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 05 Apr 2019 14:35:33 +0200] rev 42130
pull: improved message issued in case of failed update When running `hg pull --update`, the update step may fail. Nothing in the error message help to understand the abort is related to the secondary step (update) instead of the primary step (pull). We now add some information to the error message to clarify it comes from the update part. It is useful in various situation (uncommitted changes blocking the update, update to hidden destination, etc...) The pull output is updated from: $ hg pull ../repo-Bob --rev 956063ac4557 --update pulling from ../repo-Bob searching for changes adding changesets adding manifests adding file changes added 2 changesets with 0 changes to 2 files (+1 heads) (2 other changesets obsolete on arrival) abort: filtered revision '6'! to: $ hg pull ../repo-Bob --rev 956063ac4557 --update pulling from ../repo-Bob searching for changes adding changesets adding manifests adding file changes added 2 changesets with 0 changes to 2 files (+1 heads) (2 other changesets obsolete on arrival) abort: cannot update to target: filtered revision '6'! (I am not sure why the actual error, "filtered revision '6'", is not using the more modern format mentioning the obsolescence fate of '6')
Fri, 05 Apr 2019 15:56:05 +0200 pull: deal with locally filtered changeset passed into --rev
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 05 Apr 2019 15:56:05 +0200] rev 42129
pull: deal with locally filtered changeset passed into --rev Nowadays, it is possible to explicitly pull a remote revision that end up being hidden locally (eg: obsoleted locally). However before this patch, some internal processing where crashing trying to resolve a filtered revision. Without this patches, the pull output result a confusing output: $ hg pull ../repo-Bob --rev 956063ac4557 pulling from ../repo-Bob searching for changes adding changesets adding manifests adding file changes added 2 changesets with 0 changes to 2 files (+1 heads) (2 other changesets obsolete on arrival) abort: 00changelog.i@956063ac4557828781733b2d5677a351ce856f59: filtered node!
Mon, 15 Apr 2019 22:13:11 -0700 absorb: aborting if another operation is in progress
Rodrigo Damazio Bovendorp <rdamazio@google.com> [Mon, 15 Apr 2019 22:13:11 -0700] rev 42128
absorb: aborting if another operation is in progress This increases safety of using absorb by both aborting when another operation is in progress (since the absorption could confuse any other command a lot) and holding the locks throughout the reading of the working directory (for which changes to absorb) and the reading of the repo (for which changes to absorb into). Differential Revision: https://phab.mercurial-scm.org/D6237
Thu, 04 Apr 2019 13:58:49 +0200 repoview: keep the branchmap cache for the `served.hidden` view warm
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 04 Apr 2019 13:58:49 +0200] rev 42127
repoview: keep the branchmap cache for the `served.hidden` view warm For the same reason we want to keep the cache for the `served` view up to date, we want to also keep the `served.hidden` view up to date. If some processes with a readonly access to the repo needs to access it, we better have the cache warm to avoid computing the same data over and over and over. In most case (no secret changesets), the "served" and "served.hidden" set will be identical and no cache will actually have to be updated.
Mon, 21 May 2018 17:28:35 +0200 repoview: introduce a filter for serving hidden changesets
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 21 May 2018 17:28:35 +0200] rev 42126
repoview: introduce a filter for serving hidden changesets There are multiple usecase for being able to explicitly view or pull obsolete from a server. We need to be able to do so without exposing the secret changesets. We introduces a dedicated repository "view" to do so. Way to expose this "view" to the user will come later. To keep a behavior consistent with expected client/server behavior, the general idea is for the obsolete access to be explicitly requested by the code generating the request. In addition, the will be server side configuration to restrict the access to this feature.
Sat, 13 Apr 2019 20:57:50 +0200 repoview: fix conditional around unserved changesets
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 13 Apr 2019 20:57:50 +0200] rev 42125
repoview: fix conditional around unserved changesets The conditional could lead to wrong computation since we have more unserved changesets than just the "secret" phase. In addition, now that we have efficient caching of phased changesets, we don't need the conditional anymore.
Fri, 05 Apr 2019 16:05:20 +0300 branch: return early if we find an open named branch apart from default
Pulkit Goyal <pulkit@yandex-team.ru> [Fri, 05 Apr 2019 16:05:20 +0300] rev 42124
branch: return early if we find an open named branch apart from default The current code builds a list of all the open named branches except default and then bool that. This is mostly fine until you get a repo which has thousands of named branches. Differential Revision: https://phab.mercurial-scm.org/D6211
Fri, 05 Apr 2019 15:57:09 +0300 branchcache: don't verify closed nodes in _branchtip()
Pulkit Goyal <pulkit@yandex-team.ru> [Fri, 05 Apr 2019 15:57:09 +0300] rev 42123
branchcache: don't verify closed nodes in _branchtip() We only do membership testing there. Differential Revision: https://phab.mercurial-scm.org/D6210
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip