path: directly use the push_variant in `hg summary`
We don't need any extra processing now.
path: directly use the push_variant in `hg outgoing`
We don't need any extra processing now.
path: directly use the push_variant in `hg push`
We don't need any extra processing now.
path: have `get_push_paths` directly return the push variants
So the function directly returns usable paths, that should help the callers!
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.
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.
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.
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.
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.