Sat, 13 Apr 2019 03:44:55 +0200 hidden: add support to explicitly access hidden changesets with SSH peers
Manuel Jacob <me@manueljacob.de> [Sat, 13 Apr 2019 03:44:55 +0200] rev 50420
hidden: add support to explicitly access hidden changesets with SSH peers This implements support for using --remote-hidden with an SSH server. The remote `hg serve --stdio` call is passed the `--hidden` flag as a request to access hidden changesets. This approach has benefits similar to the one we used for HTTP peers. It * works around the lack of global parameters in wire protocol v1, * reuses the `--hidden` flag (that does not use the wireproto), and * can be safely ignored by older client (fitting the best effort contract). Same as for HTTP, the feature is experimental so we have all the room we needs to update the implementation in the future if deemed necessary. The SSH version of the `--remote-hidden` config uses the same configuration as the HTTP support to control the access to this feature. The name of the user running the command is used for the checking. Test written by Pierre-Yves David.
Sat, 13 Apr 2019 03:44:47 +0200 hidden: support passing --hidden with `serve --stdio`
Manuel Jacob <me@manueljacob.de> [Sat, 13 Apr 2019 03:44:47 +0200] rev 50419
hidden: support passing --hidden with `serve --stdio` This currently has no effect since the server code will filter the repository again. However, it is clearer to put this change in its own changeset. This will mostly impact ssh peers, clients being now able to pass --hidden when spawning the server. See the next changeset for details on how this is going to be used.
Sat, 13 Apr 2019 01:53:59 +0200 hgweb: move ismember from `hgweb.common` to `scmutil`
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 13 Apr 2019 01:53:59 +0200] rev 50418
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.
Fri, 05 Apr 2019 01:17:15 +0200 hidden: add support for --remote-hidden to HTTP peer
Manuel Jacob <me@manueljacob.de> [Fri, 05 Apr 2019 01:17:15 +0200] rev 50417
hidden: add support for --remote-hidden to HTTP peer Test written by Pierre-Yves David.
Sat, 13 Apr 2019 02:01:26 +0200 hidden: add support to explicitly access hidden changesets via HTTP
Manuel Jacob <me@manueljacob.de> [Sat, 13 Apr 2019 02:01:26 +0200] rev 50416
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.
Sat, 13 Apr 2019 02:00:20 +0200 hidden: support for explicitly accessing hidden changesets in wireproto server
Manuel Jacob <me@manueljacob.de> [Sat, 13 Apr 2019 02:00:20 +0200] rev 50415
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.
Fri, 05 Apr 2019 12:11:52 +0200 hidden: add support for --remote-hidden to localpeer
Manuel Jacob <me@manueljacob.de> [Fri, 05 Apr 2019 12:11:52 +0200] rev 50414
hidden: add support for --remote-hidden to localpeer
Thu, 04 Apr 2019 18:07:30 +0200 pull: add --remote-hidden option and pass it through peer creation
Manuel Jacob <me@manueljacob.de> [Thu, 04 Apr 2019 18:07:30 +0200] rev 50413
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.
Sat, 13 Apr 2019 01:17:56 +0200 hgweb: add support to explicitly access hidden changesets
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 13 Apr 2019 01:17:56 +0200] rev 50412
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.
Tue, 14 Mar 2023 05:30:34 +0100 clone-bundles: add an option to generate bundles in the background
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 14 Mar 2023 05:30:34 +0100] rev 50411
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.
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 tip