Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 08 Apr 2021 00:34:16 +0200] rev 47038
revlog: code for `revlogv0` in its own module
This code is mostly unused compatiblity code. Yet it take a prohiminent place in
the `revlog.py` module. That module is already quite big, so we move all that
code in a dedicated module.
Differential Revision: https://phab.mercurial-scm.org/D10511
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 01 Apr 2021 11:31:54 +0200] rev 47037
revlog: have an explicit "pack_header" method
Having to pass the version header when retrieving the binary version of every
single entry is a bit silly. So we extract that special logic in its own method.
This also prepare the move to newer revlog format, not storing the header within
an actual entry…
Differential Revision: https://phab.mercurial-scm.org/D10510
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 01 May 2021 14:47:39 +0200] rev 47036
revlog: remove the revlogio class
The class only contains a single `parseindex` method. Lets just make it a
function and remove the `revlogio` class. It served us well but became thinner
and thinner overtime.
Differential Revision: https://phab.mercurial-scm.org/D10509
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 01 May 2021 14:47:33 +0200] rev 47035
revlog: fix some comment style
They displease check-code.
Differential Revision: https://phab.mercurial-scm.org/D10542
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 08 Apr 2021 00:01:11 +0200] rev 47034
revlog: add a `entry_binary` method on index
The revlog index is already responsible for unpacking the binary entry, it would be
simpler to make it responsible for packing them. In practice the C version of
the index is already doing this internally.
We introduce a "entry_binary" method that return the binary version of an
existing revision. The method currently need to also take the revlog header to
deal with the "first revision" special case. We will introduce further refactor
in a later changeset to split that logic out.
Differential Revision: https://phab.mercurial-scm.org/D10508
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 15 Apr 2021 12:08:34 +0200] rev 47033
template: make an explicit closure for formatting entry in peerurls
This is about to be become significantly more complicated as `ui.path[x]` will
become a list.
Differential Revision: https://phab.mercurial-scm.org/D10443
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 15 Apr 2021 11:50:08 +0200] rev 47032
template: use `list_paths` in `peerurls`
Using common code will make it simpler to update the logic behind the path
definition and storage.
Differential Revision: https://phab.mercurial-scm.org/D10442
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 15 Apr 2021 11:48:29 +0200] rev 47031
paths: use `list_paths` in `hg paths`
Using common code will make it simpler to update the logic behind the path
definition and storage.
Differential Revision: https://phab.mercurial-scm.org/D10441
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 15 Apr 2021 11:46:31 +0200] rev 47030
urlutil: introduce a new `list_paths` function
This function will be useful for command and template that wants to display path
related information.
Differential Revision: https://phab.mercurial-scm.org/D10440
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 15 Apr 2021 10:05:51 +0200] rev 47029
urlutil: deprecate `getpath`
There as no remaining user of that function.
Differential Revision: https://phab.mercurial-scm.org/D10439
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 15 Apr 2021 10:01:44 +0200] rev 47028
urlutil: inline the relevant part of `getpath` in `get_push_paths`
The part that `get_push_paths` needs is quite simple, inclining will help us
to deprecated `getpath`.
Differential Revision: https://phab.mercurial-scm.org/D10438
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 15 Apr 2021 09:50:56 +0200] rev 47027
url_util: introduce a `try_path` function
That function… try a build a path, returning None on failure. This helps us to simplify various part of the existing code.
Differential Revision: https://phab.mercurial-scm.org/D10437
Martin von Zweigbergk <martinvonz@google.com> [Tue, 20 Apr 2021 11:22:35 -0700] rev 47026
narrow: add more status messages when narrowing
Each of the steps I added status messages for in this patch frequently
take minutes or tens of minutes for our internal users.
It would be nice to also have a progress bar but that will have to
come later.
Differential Revision: https://phab.mercurial-scm.org/D10503
Martin von Zweigbergk <martinvonz@google.com> [Tue, 20 Apr 2021 10:24:03 -0700] rev 47025
narrow: add progress-reporting when looking for local changes in `hg tracked`
Looking for local changes (changes not on the given remote) can take a
long time, so we should have progress-reporting for it.
Differential Revision: https://phab.mercurial-scm.org/D10501
Kyle Lippincott <spectral@google.com> [Fri, 16 Apr 2021 16:21:26 -0700] rev 47024
chg: pass --no-profile to disable profiling when starting hg serve
If profiling is enabled via global/user config (as far as I can tell, this
doesn't affect use of the --profile flag, but it probably does affect --config
profiling.enabled=1), then the profiling data can be *cumulative* for the
lifetime of the chg process.
This leads to some "interesting" results where hg claims the walltime is
something like 200s on a command that took only a second or two to run. Worse,
however, is that with at least some profilers (such as the default "stat"
profiler), this can cause a large slowdown while generating the profiler output.
Differential Revision: https://phab.mercurial-scm.org/D10470
Kyle Lippincott <spectral@google.com> [Fri, 16 Apr 2021 15:31:05 -0700] rev 47023
profiling: add --no-profile to disable profiling enabled via config
Differential Revision: https://phab.mercurial-scm.org/D10469