Joerg Sonnenberger <joerg@bec.de> [Tue, 20 Oct 2020 17:32:45 +0200] rev 45790
phases: convert registernew users to use revision sets
Differential Revision: https://phab.mercurial-scm.org/D9233
Joerg Sonnenberger <joerg@bec.de> [Mon, 19 Oct 2020 02:54:12 +0200] rev 45789
phases: allow registration and boundary advancement with revision sets
The core internals either use revision sets already or can trivially use
them. Use the new interface in cg1unpacker.apply to avoid materializing
the list of all new nodes as it is normally just a revision range. This
avoids about 67 Bytes / changeset on AMD64 in peak RSS.
Differential Revision: https://phab.mercurial-scm.org/D9232
Joerg Sonnenberger <joerg@bec.de> [Sun, 18 Oct 2020 22:18:02 +0200] rev 45788
revlog: extend addgroup() with callback for duplicates
The addgroup() interface currently doesn't allow the caller to keep
track of duplicated nodes except by looking at the returned node list.
Add an optional second callback for this purpose and change the return
type to a boolean. This allows follow-up changes to use more efficient
storage for the node list in places that are memory-sensitive.
Differential Revision: https://phab.mercurial-scm.org/D9231
Pulkit Goyal <7895pulkit@gmail.com> [Wed, 07 Oct 2020 14:26:47 +0530] rev 45787
tags: add safety check for len(record) while reading hgtagsfnodescache
I am trying to fix a breakage where somehow we end up getting a node of 12
length from `getfnode()`. Understanding the hgtagsfnodescache code, it seems
highly unlikely that it can happen unless one of `mctx.readfast().get()` or
`ctx.filenode()` is returning a node of 12 length.
For safety, I think it's better to add a check to make sure that record which we
are parsing is of same length we are expecting otherwise we consider that as
invalid record.
Differential Revision: https://phab.mercurial-scm.org/D9169
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 14 Oct 2020 17:52:18 +0200] rev 45786
procutil: allow to specify arbitrary stdin bytes to runbgcommand
For automatic clonebundles generation I need to pass arbitrary large amount of
data to the process (eg: common nodes, target nodes).
I am updating the `runbgcommand` to allow for this. Previously not stdin input
was possible, now, one can provide raw bytes and they will be feed to the
command through an unnamed temporary files.
Differential Revision: https://phab.mercurial-scm.org/D9212
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 14 Oct 2020 17:46:28 +0200] rev 45785
clonebundle: move the manifest filename to a constant
I am about to add more reference to it, so I would rather have it an explicit
constant. This allow to unify various call too.
Differential Revision: https://phab.mercurial-scm.org/D9209
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 15 Oct 2020 15:57:36 +0200] rev 45784
clonebundles: move a bundle of clone bundle related code to a new module
In the process on general clone bundle automatically, we need to make some
function available more widely. This is a good opportunity to extract a
significant amount of code from `mercurial.exchange` into a new
`mercurial.bundlecaches`. This make `mercurial.exchange` move under the 3K line
range (hooray…).
The module is called `bundlecaches` because I expect it to be eventually useful
for more than just clone bundle (like pull bunbles).
Differential Revision: https://phab.mercurial-scm.org/D9208
Pulkit Goyal <7895pulkit@gmail.com> [Wed, 01 Jul 2020 15:14:59 +0530] rev 45783
config: add a .hg/hgrc-not-shared which won't be shared in share-safe mode
Previous patches add a safe mode for sharing repositories which involve sharing
of source requirements and config files.
In certain situations we might need to add a config to source repository which
we does not want to share. For this, we add a `.hg/hgrc-not-shared` which won't
be shared.
This also adds a `--non-shared` flag to `hg config` command to see the
non-shared config.
Differential Revision: https://phab.mercurial-scm.org/D8673
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 18 Sep 2020 18:52:38 +0530] rev 45782
dispatch: load shared source repository config in share-safe mode
It seems to me now that there are two steps when config is loaded:
1) on dispatch
2) repository object creation
Recent patches added functionality that there can be shares in share-safe mode
where config of the source repository is shared with the the shares. However we
missed adding logic to read the source config on dispatch. This leads to
extensions not being loaded on dispatch and hence extensions command not being
recognized.
This patch fixes it by reading the shared source config on dispatch.
Differential Revision: https://phab.mercurial-scm.org/D9047
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 18 Sep 2020 17:28:22 +0530] rev 45781
tests: add test showing broken extension loading in case of share-safe
When we are using share-safe and loading source repository config, we are still
not loading the extensions which are enabled in the source repository.
This patch demonstrates the bug. Meanwhile it also shows how unreliable `hg
debugextensions` is.
Differential Revision: https://phab.mercurial-scm.org/D9046