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
Fri, 05 Apr 2019 15:56:33 +0300 branchcache: don't verify closed nodes in iteropen()
Pulkit Goyal <pulkit@yandex-team.ru> [Fri, 05 Apr 2019 15:56:33 +0300] rev 42122
branchcache: don't verify closed nodes in iteropen() We expect that the nodes passed to iteropen() will be verified. We are only testing for membership in closed nodes set, so we don't need to verify the whole closed nodes set. This will speed up calculating branchheads() when there are lot of closed nodes related to other branches. Differential Revision: https://phab.mercurial-scm.org/D6209
Mon, 01 Apr 2019 13:56:47 +0300 branchcache: lazily validate nodes from the branchmap
Pulkit Goyal <pulkit@yandex-team.ru> [Mon, 01 Apr 2019 13:56:47 +0300] rev 42121
branchcache: lazily validate nodes from the branchmap On my personal hg-repository with 365 entries in .hg/cache/branch2, following are the numbers for perfbranchmapload. Before this patch: ! wall 0.000866 comb 0.000000 user 0.000000 sys 0.000000 (best of 2680) ! wall 0.001525 comb 0.000000 user 0.000000 sys 0.000000 (max of 2680) ! wall 0.001107 comb 0.001097 user 0.001086 sys 0.000011 (avg of 2680) ! wall 0.001104 comb 0.000000 user 0.000000 sys 0.000000 (median of 2680) With this patch: ! wall 0.000530 comb 0.000000 user 0.000000 sys 0.000000 (best of 4240) ! wall 0.001078 comb 0.000000 user 0.000000 sys 0.000000 (max of 4240) ! wall 0.000696 comb 0.000693 user 0.000677 sys 0.000017 (avg of 4240) ! wall 0.000690 comb 0.000000 user 0.000000 sys 0.000000 (median of 4240) On our internal repository with ~20k entries in branchcache, I see improvement from 0.125 sec to 0.066 sec which is 47% speed up. The above are the numbers of perfbranchmapload which shows how much time we saved by not validating the nodes. But we need to validate some nodes. Following are timings of some mercurial operations which have speed up because of this lazy validation of nodes: No-op `hg update` on our internal repository (Avg on 4 runs): Before: 0.540 secs After: 0.430 secs Setting a branch name which already exists without --force (Avg of 4 runs): Before: 0.510 secs After: 0.250 secs I ran the ASV performance suite and was unable to see any improvements except there was improvement of perfdirstatewrite() on netbeans which I think was not related. I looked into the commit code, the command which I am trying to speedup, it looks like it uses revbranchcache to update the branchcache. Differential Revision: https://phab.mercurial-scm.org/D6208
Tue, 19 Mar 2019 16:52:15 +0300 branchcache: add functions to validate changelog nodes
Pulkit Goyal <pulkit@yandex-team.ru> [Tue, 19 Mar 2019 16:52:15 +0300] rev 42120
branchcache: add functions to validate changelog nodes This patch adds functions to validate closed nodes, validate nodes for a certain branch and for all the branches. These functions will be used in upcoming patches. Differential Revision: https://phab.mercurial-scm.org/D6207
Mon, 15 Apr 2019 14:32:47 -0700 readline: provide styled prompt to readline (issue6070)
Kyle Lippincott <spectral@google.com> [Mon, 15 Apr 2019 14:32:47 -0700] rev 42119
readline: provide styled prompt to readline (issue6070) Differential Revision: https://phab.mercurial-scm.org/D6168
Tue, 02 Apr 2019 14:49:28 -0700 copies: move comment about implementation of mergecopies() to end
Martin von Zweigbergk <martinvonz@google.com> [Tue, 02 Apr 2019 14:49:28 -0700] rev 42118
copies: move comment about implementation of mergecopies() to end When you start reading about mergecopies(), you want to know what it is, not that there are different implementations depending on config, so this patch moves that comment to the end. By the way, we don't seem to define what "copytracing" is. I'm just leaving it that way because I don't know what it is myself. It seems to be referred to only on mergecopies() (and not in pathcopies(), for example), so maybe "copytracing" is supposed to be exactly what mergecopies() does? Differential Revision: https://phab.mercurial-scm.org/D6235
Fri, 12 Apr 2019 23:26:08 -0700 remotefilelog: return expected type from copies overrides
Martin von Zweigbergk <martinvonz@google.com> [Fri, 12 Apr 2019 23:26:08 -0700] rev 42117
remotefilelog: return expected type from copies overrides copies._computeforwardmissing() and copies._computenonoverlap() return sets, so the overrides should also do that. Differential Revision: https://phab.mercurial-scm.org/D6234
Sun, 24 Mar 2019 23:47:01 -0700 changelog: extract a _string_unescape() to mirror _string_escape()
Martin von Zweigbergk <martinvonz@google.com> [Sun, 24 Mar 2019 23:47:01 -0700] rev 42116
changelog: extract a _string_unescape() to mirror _string_escape() We use our own _string_escape() to encode the "extras" field. Then we use codecs.escape_decode() to escape it. But there's also a little workaround for dealing with escaped text that looks like octal numbers since the fix for https://bz.mercurial-scm.org/show_bug.cgi?id=3156. This patch extracts the call to codecs.escape_decode() along with the fix for octal numbers and puts it in a _string_unescape(). It also updates the test to check for the octal-number case from the aforementioned bug. As you may have suspected, I want to be able to reuse this new function later. Differential Revision: https://phab.mercurial-scm.org/D6184
Wed, 20 Mar 2019 11:42:02 -0700 copies: extract function for deciding whether to use changeset-centric algos
Martin von Zweigbergk <martinvonz@google.com> [Wed, 20 Mar 2019 11:42:02 -0700] rev 42115
copies: extract function for deciding whether to use changeset-centric algos We'll eventually have a "experimental.copies.read-from=changeset-only" option too and I don't want to spread the logic for determining if we should use changeset-centric of filelog-centric algorithms. Differential Revision: https://phab.mercurial-scm.org/D6163
Fri, 18 Jan 2019 13:13:48 -0800 getrenamedfn: get copy data from context object if configured
Martin von Zweigbergk <martinvonz@google.com> [Fri, 18 Jan 2019 13:13:48 -0800] rev 42114
getrenamedfn: get copy data from context object if configured The function returned from getrenamedfn() calls filelog.renamed(). That won't work when storing copy metadata in the changeset. I've just switched to a simple implementation here. We may or may not need to optimize it later, possibly by optimizing the callers. No more tests fail with "--extra-config-opt experimental.copies.read-from=compatibility)" than they did before this patch. Differential Revision: https://phab.mercurial-scm.org/D6162
Sun, 31 Mar 2019 16:27:10 +0300 branchmap: implement __contains__()
Pulkit Goyal <pulkit@yandex-team.ru> [Sun, 31 Mar 2019 16:27:10 +0300] rev 42113
branchmap: implement __contains__() We have good occurences of `if branch in branchmap()` in our code. If __contains__() is not implemented then it will use __iter__() to find whether the element exists or not which is not good. I am bit confused that whether I should move existing callers to hasbranch() or this patch is a good way. Differential Revision: https://phab.mercurial-scm.org/D6206
Sun, 31 Mar 2019 16:20:17 +0300 branchmap: prevent using __getitem__() in branchheads()
Pulkit Goyal <pulkit@yandex-team.ru> [Sun, 31 Mar 2019 16:20:17 +0300] rev 42112
branchmap: prevent using __getitem__() in branchheads() branchheads() can directly use self._entries instead. Differential Revision: https://phab.mercurial-scm.org/D6205
Wed, 27 Mar 2019 21:33:04 +0300 branchmap: dynamically resolve type of branchcache class
Pulkit Goyal <pulkit@yandex-team.ru> [Wed, 27 Mar 2019 21:33:04 +0300] rev 42111
branchmap: dynamically resolve type of branchcache class This is required to support subclassing. Thanks to Yuya for suggesting this in D6151. Differential Revision: https://phab.mercurial-scm.org/D6204
Fri, 12 Apr 2019 09:41:08 -0700 copies: print list of divergent renames in sorted order
Martin von Zweigbergk <martinvonz@google.com> [Fri, 12 Apr 2019 09:41:08 -0700] rev 42110
copies: print list of divergent renames in sorted order The current order is not obvious to the user (and I may change it in a later patch). Lexicographical order seems like the obvious choice here. Differential Revision: https://phab.mercurial-scm.org/D6227
Fri, 12 Apr 2019 12:20:38 -0400 import: suppress accept: header
timeless <timeless@mozdev.org> [Fri, 12 Apr 2019 12:20:38 -0400] rev 42109
import: suppress accept: header irccloud and others may perform content negotation and reject (406) if the accept header does not match the mime type of the object
Fri, 12 Apr 2019 12:06:13 -0400 rebase: fix bug that prevented dry-run rebases from printing failures
Augie Fackler <augie@google.com> [Fri, 12 Apr 2019 12:06:13 -0400] rev 42108
rebase: fix bug that prevented dry-run rebases from printing failures As far as I can tell it should be fine to unconditionally skip _prepareabortorcontinue if we're in the process of raising an Abort here. Differential Revision: https://phab.mercurial-scm.org/D6226
Fri, 12 Apr 2019 11:41:33 -0400 rebase: demonstrate bug in dry-run mode which causes cycles to not be reported
Augie Fackler <augie@google.com> [Fri, 12 Apr 2019 11:41:33 -0400] rev 42107
rebase: demonstrate bug in dry-run mode which causes cycles to not be reported Differential Revision: https://phab.mercurial-scm.org/D6225
Sat, 06 Apr 2019 17:48:11 +0200 test: minor cleanup to test-server-view.t
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 06 Apr 2019 17:48:11 +0200] rev 42106
test: minor cleanup to test-server-view.t While looking into adding error output in this test, I did some cleanup.
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -28 +28 +50 +100 +300 +1000 +3000 tip