Thu, 01 Dec 2022 18:41:59 +0100 path: pass `path` to `peer` in `hg pull`
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 01 Dec 2022 18:41:59 +0100] rev 49831
path: pass `path` to `peer` in `hg pull` We directly use the `path` object to build the `peer` object. We don't use it for sub-repositories yet, which will have to be fixed at some point.
Thu, 01 Dec 2022 18:19:08 +0100 path: pass `path` to `peer` in `hg incoming`
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 01 Dec 2022 18:19:08 +0100] rev 49830
path: pass `path` to `peer` in `hg incoming` We directly use the `path` object to build the `peer` object. We don't use it for sub-repositories yet, which will have to be fixed at some point.
Thu, 01 Dec 2022 17:55:17 +0100 path: pass `path` to `peer` in `hg incoming` bookmark logic
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 01 Dec 2022 17:55:17 +0100] rev 49829
path: pass `path` to `peer` in `hg incoming` bookmark logic We directly use the `path` object to build the `peer` object. Touching this code highlighted that we never honor the branches' information of when doing bookmark level incoming checks.
Thu, 01 Dec 2022 16:58:22 +0100 path: remove outdated documentation point from `get_unique_pull_path`
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 01 Dec 2022 16:58:22 +0100] rev 49828
path: remove outdated documentation point from `get_unique_pull_path` This is no longer true.
Thu, 01 Dec 2022 16:53:22 +0100 path: update `get_unique_pull_path` to point out it returns a url
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 01 Dec 2022 16:53:22 +0100] rev 49827
path: update `get_unique_pull_path` to point out it returns a url Unlike other functions in this module it returns a url as `bytes` and not a `path` object. Let us point it out in the doc.
Fri, 02 Dec 2022 02:03:49 +0100 changelog-v2: fix the docket `struct`
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 02 Dec 2022 02:03:49 +0100] rev 49826
changelog-v2: fix the docket `struct` The previous definition used `L` which is actually 4 bytes, while the documentation and intend was to use `Q`, i.e. 8 bytes.
Thu, 01 Dec 2022 02:26:34 +0100 path: pass `path` to `peer` in infinite push
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 01 Dec 2022 02:26:34 +0100] rev 49825
path: pass `path` to `peer` in infinite push We directly use the `path` object to build the `peer` object.
Thu, 01 Dec 2022 02:21:18 +0100 path: pass `path` to `peer` in `hg histedit`
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 01 Dec 2022 02:21:18 +0100] rev 49824
path: pass `path` to `peer` in `hg histedit` We directly use the `path` object to build the `peer` object.
Thu, 01 Dec 2022 02:14:40 +0100 path: pass `path` to `peer` in the `outgoing` revset
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 01 Dec 2022 02:14:40 +0100] rev 49823
path: pass `path` to `peer` in the `outgoing` revset We directly use the `path` object to build the `peer` object.
Thu, 01 Dec 2022 02:11:21 +0100 path: pass `path` to `peer` in `hg summary`
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 01 Dec 2022 02:11:21 +0100] rev 49822
path: pass `path` to `peer` in `hg summary` We directly use the `path` object to build the `peer` object.
Thu, 01 Dec 2022 02:09:43 +0100 path: pass `path` to `peer` in `hg outgoing`
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 01 Dec 2022 02:09:43 +0100] rev 49821
path: pass `path` to `peer` in `hg outgoing` We directly use the `path` object to build the `peer` object.
Thu, 01 Dec 2022 01:57:14 +0100 path: pass `path` to `peer` in `hg bundle`
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 01 Dec 2022 01:57:14 +0100] rev 49820
path: pass `path` to `peer` in `hg bundle` We directly use the `path` object to build the `peer` object.
Wed, 30 Nov 2022 19:43:26 +0100 path: have `peer` constructor accept a `path` object
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 30 Nov 2022 19:43:26 +0100] rev 49819
path: have `peer` constructor accept a `path` object We don't do anything fancy with it yet, but this is an important step towards having the peers aware of their "source" and associated configurations.
Thu, 01 Dec 2022 01:46:46 +0100 path: deprecated the `pushloc` attribute
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 01 Dec 2022 01:46:46 +0100] rev 49818
path: deprecated the `pushloc` attribute We want to make sure people with use the full featured path "variant".
Thu, 01 Dec 2022 01:41:34 +0100 path: update logic in `perf` to use the push variant when available
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 01 Dec 2022 01:41:34 +0100] rev 49817
path: update logic in `perf` to use the push variant when available The command seems currently broken, but at least it won't be broken by us !
Thu, 01 Dec 2022 01:38:33 +0100 path: directly use the push_variant in `infinitepush`
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 01 Dec 2022 01:38:33 +0100] rev 49816
path: directly use the push_variant in `infinitepush` We don't need any extra processing now.
Thu, 01 Dec 2022 01:38:07 +0100 path: directly use the push_variant in `hg histedit` outgoing logic
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 01 Dec 2022 01:38:07 +0100] rev 49815
path: directly use the push_variant in `hg histedit` outgoing logic We don't need any extra processing now.
Thu, 01 Dec 2022 01:37:41 +0100 path: directly use the push_variant in the `outgoing` revset
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 01 Dec 2022 01:37:41 +0100] rev 49814
path: directly use the push_variant in the `outgoing` revset We don't need any extra processing now.
Thu, 01 Dec 2022 01:37:10 +0100 path: directly use the push_variant in outgoing internals
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 01 Dec 2022 01:37:10 +0100] rev 49813
path: directly use the push_variant in outgoing internals We don't need any extra processing now.
Thu, 01 Dec 2022 01:35:17 +0100 path: directly use the push_variant in `hg summary`
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 01 Dec 2022 01:35:17 +0100] rev 49812
path: directly use the push_variant in `hg summary` We don't need any extra processing now.
Thu, 01 Dec 2022 01:34:58 +0100 path: directly use the push_variant in `hg outgoing`
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 01 Dec 2022 01:34:58 +0100] rev 49811
path: directly use the push_variant in `hg outgoing` We don't need any extra processing now.
Thu, 01 Dec 2022 01:34:26 +0100 path: directly use the push_variant in `hg push`
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 01 Dec 2022 01:34:26 +0100] rev 49810
path: directly use the push_variant in `hg push` We don't need any extra processing now.
Thu, 01 Dec 2022 01:33:27 +0100 path: have `get_push_paths` directly return the push variants
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 01 Dec 2022 01:33:27 +0100] rev 49809
path: have `get_push_paths` directly return the push variants So the function directly returns usable paths, that should help the callers!
Thu, 01 Dec 2022 01:32:24 +0100 path: add a method to retrieve a "push variant" of a path
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 01 Dec 2022 01:32:24 +0100] rev 49808
path: add a method to retrieve a "push variant" of a path This gets you the same path, but using the `pushurl` as destination. This opens the way for a lot of different improvements, the one which interests us is having `peer` objects aware of the `path` they came from.
Thu, 01 Dec 2022 01:27:47 +0100 path: move the url parsing and related attribute setting to a method
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 01 Dec 2022 01:27:47 +0100] rev 49807
path: move the url parsing and related attribute setting to a method This will make it simpler to reuse this logic in the next changeset.
Tue, 29 Nov 2022 22:22:18 +0100 peer-or-repo: remove the now unused function
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 29 Nov 2022 22:22:18 +0100] rev 49806
peer-or-repo: remove the now unused function We do not need it anymore.
Tue, 29 Nov 2022 22:21:19 +0100 peer-or-repo: build a repo directly in the `repo` function
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 29 Nov 2022 22:21:19 +0100] rev 49805
peer-or-repo: build a repo directly in the `repo` function We skip the ambiguous _peerorrepo function to explicitly build a repo within the dedicated function. The peer scheme are therefore no longer considered to build the object.
Tue, 29 Nov 2022 22:04:23 +0100 peer-or-repo: build a peer directly in the `peer` function
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 29 Nov 2022 22:04:23 +0100] rev 49804
peer-or-repo: build a peer directly in the `peer` function We skip the ambiguous _peerorrepo function to explicitly build a peer within the dedicated function. This mean explicitly getting a peer from an explicitly create repository when necessary.
Tue, 29 Nov 2022 22:03:10 +0100 static-http: have `statichttprepo.instance` return a peer object
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 29 Nov 2022 22:03:10 +0100] rev 49803
static-http: have `statichttprepo.instance` return a peer object It previously returned a statichttprepo object which could not be used for anything but creating a peer. So lets put it into the peer bucket with a peer behavior.
Wed, 30 Nov 2022 12:22:02 +0100 scheme: move the drive letter checking in its own function
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 30 Nov 2022 12:22:02 +0100] rev 49802
scheme: move the drive letter checking in its own function This help the readability of the main function as is was taking much more room than the main logic.
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 tip