Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 13 Apr 2019 01:53:59 +0200] rev 50445
hgweb: move ismember from `hgweb.common` to `scmutil`
To implement hidden access control for other protocol than http, we need code
outside of hgweb to access this logic.
Manuel Jacob <me@manueljacob.de> [Fri, 05 Apr 2019 01:17:15 +0200] rev 50444
hidden: add support for --remote-hidden to HTTP peer
Test written by Pierre-Yves David.
Manuel Jacob <me@manueljacob.de> [Sat, 13 Apr 2019 02:01:26 +0200] rev 50443
hidden: add support to explicitly access hidden changesets via HTTP
We now detect hidden access request and validate them while handling HTTP
wireprotocol command. This changeset only introduces server support. Client
support is added in a subsequent changeset.
The mechanism we use for the HTTP wireprotocol is the same as the one used to
lift filtering for hgweb. The use of the global `access-hidden` parameter in
the http url is a simple and effective approach that
* works around the lack of global parameters in wire protocol v1,
* reuses the mechanism used for hgweb (that does not use the wireproto), and
* can be safely ignored by older client (fitting the best effort contract).
The feature is still experimental, so we can easily update the implementation
details in the future. However, landing a first implementation now will help
test the feature in the wild and iterate on alternative implementations if
deemed necessary.
Manuel Jacob <me@manueljacob.de> [Sat, 13 Apr 2019 02:00:20 +0200] rev 50442
hidden: support for explicitly accessing hidden changesets in wireproto server
This installs the basic infrastructure to be able to access hidden changeset
through the wireprotocol. Each wireprotocol server still needs a way to define
how the feature is triggered.
Manuel Jacob <me@manueljacob.de> [Fri, 05 Apr 2019 12:11:52 +0200] rev 50441
hidden: add support for --remote-hidden to localpeer
Manuel Jacob <me@manueljacob.de> [Thu, 04 Apr 2019 18:07:30 +0200] rev 50440
pull: add --remote-hidden option and pass it through peer creation
This option will allow to pull changesets that are hidden on the remote. This
is useful when looking into a changeset’s evolution history, resolving
evolution instability or mirroring a repository.
The option is best effort and will only affect the pull when it can. The option
will be ignored when it cannot be honored.
Support for each type of peer is yet to be implemented. They currently all warn
about lack of support. The warning code will get removed as peers gain
support for this option.
The option is still experimental, so we will have freedom to update the UI or
implementation before it graduates out of experimental.
Based on a changeset by Pierre-Yves David, which added the option.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 13 Apr 2019 01:17:56 +0200] rev 50439
hgweb: add support to explicitly access hidden changesets
This changeset adds a "global" `access-hidden` argument to hgweb. This argument
lift the "hidden" filtering. This means the request has access to hidden (eg:
obsolete) changesets. Secret changesets remains filtered.
This feature has multiple applications. The first main use case is to allow the
hgweb interface to display more obsolescence related data, such as the Anton
Shestakov work to add `obslog` support to hgweb.
The second foreseen usecase is support for a `--remote-hidden` argument to `hg
pull` and `hg clone`. This flag will make it possible to retrieve hidden
(typically obsolete) changeset under some conditions. This is useful when
digging up obsolescence history or when doing full mirroring. More on this
feature coming in later changesets.
To avoid exposing information by mistake, access to this feature is currently
controlled with the `experimental.server.allow-hidden-access` config option. The
option works the same way as `web.allow-push`. The current default is to not
allow any hidden access. However we might change it before the feature stop
being experimental.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 14 Mar 2023 05:30:34 +0100] rev 50438
clone-bundles: add an option to generate bundles in the background
This is what the "on-change" version have been doing from the start, it seems
useful to also offer this option in the command.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 14 Mar 2023 05:09:16 +0100] rev 50437
clone-bundles: add a command to clear all bundles
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 14 Mar 2023 04:46:53 +0100] rev 50436
clone-bundles: add more test cases for automatic generation
See inline documentation for details.