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 49697
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 49696
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 18:01:24 +0400 tests: use an all too familiar executable in test-run-tests.t (issue6661) stable
Anton Shestakov <av6@dwimlabs.net> [Thu, 01 Dec 2022 18:01:24 +0400] rev 49695
tests: use an all too familiar executable in test-run-tests.t (issue6661) true(1) sometimes lives in /usr/bin/, and so this test fails on such systems. We also can't use which(1), because it's apparently not POSIX and Debian complains about it [1]. We also cannot really create a script and chmod +x it, because this is a symlink case, execbit case is slightly below. So let's use something that we know is executable, but not hg itself.
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 49694
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 49693
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 49692
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 49691
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.
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -7 +7 +10 +30 +100 +300 +1000 tip