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: remove the now unused function We do not need it anymore.

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.

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.

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.

peer-or-repo: split the scheme between repo and peer Some of the scheme will always produce a peer and some will always produce a repository. So lets use different mapping to reduce the ambiguity.

peer-or-repo: stop relying on AttributeError in `islocal` This will confused pytypes in a future changeset.

repo-or-peer: deprecate calling `islocal` on non-path object There object have a `.local()` method and should use it.

tests: add the missing space to test-hghave.t (issue6762) log() in run-tests.py add a space to the end of all messages that it prints, and I missed this fact in my previous patch.

share: stop using 'islocal' with repo instance Having this level of polymorphism of the `islocal` function is weird, and we already have a way to know if the repo is local from the object itself. We are about to deprecate passing a non-bytes object to `islocal`, so clean this up beforehand. We might want to clean up this function too in the future, however this is another adventure.

peer-or-repo: make sure object in "scheme" have a `instance` object The previous form of having heterogeneous object in the dictionnary makes things more complicated than they needed to be. I am not super happy about the current (especially around 'islocal', that most item do not have), but this is already much better.

peer-or-repo: move the object setup in its own function The `_peerorrepo` function is problematic, because it can build different types of object (repository and peer). This make it hard to adjust the arguments to the type of object we needs. So this patch start a series of change to create peer and repo without going through a common function. We move the part of the function doing object setup it its own function to make it simpler to reuse in others contexts.

delta-find: use a single snapshot cache when applying a group to an object This will avoid walking the revlog over and over again in some situations. The difference is hard to show in our current benchmark suite, as the gain is lower than their overall instability.

delta-find: make sure we only use newer full snapshot as candidate The current code does not needs to protect against this, as there are no older snapshot in the current cache. However as we are getting ready to reuse this cache from one revision to another, we need the code to protect itself about what's coming.

delta-find: use sets instead of list in the snapshot cache This seems more appropriate.

delta-find: use a smarter object for snapshot caching This open the way for a longer lived cache.

find-delta: pass the cache-delta usage policy alongside the cache-delta The idea is to give higher level code more control to what will happens with the cache delta passed. This should help with controling how we treat delta's from different sources. The final goal of this change is to allow for server modes where the client can blindly accept any server delta without regards to any local constraints. This will be implemented in later changesets.

find-delta: move most of the debug-find-delta code in the debug module Lets us that module more. It will help us to keep revlog implementation details close to each other.

find-delta: minor preparatory change We are about to add more item in the cachedelta object, so lets access the item by index instead of doing a full extensions.