checkheads: upgrade the obsolescence postprocessing logic (issue4354) The previous logic had many shortcoming (eg: looking at the head only, not handling prune, etc...), the new logic use a more robust approach: For each head, we check if after the push all changesets exclusive to this heads will be obsolete. If they are, the branch considered be "replaced". To check if a changeset will be obsolete, we simply checks: * the changeset phase * the existence of a marker relevant to the "pushed set" that affects the changesets.. This fixes two major issues of the previous algorithm: * branch partially rewritten (eg: head but not root) are no longer detected as replaced, * Prune are now properly handled. (This implementation was introduction in the evolve extension, version 6.0.0.) This new algorithm has an extended number of tests, a basic one is provided in this patch. The others will be introduced in their own changeset for clarity. In addition, we stop trying to process heads unknown locally, we do not have enough data to take an informed decision so we should stop pretending we do. This reflect a test that is now update.

test-http: add a (glob) for Windows I'm not sure why the glob was ineffective with $TESTTMP here, but replacing it with '*' works.

testlib: move the prune alias into a shell script for Windows Cramming all of this directly into an alias doesn't play nicely on Windows. Various test-exchange-obsmarkers-case-XX.t were failing with: abort: cannot select revision when creating marker It turned out that inside debugcommands.debugobsolete(), the following differed from Linux (where they were empty, at least in the case I debugged): 'rev': ['.`;'], 'template': "'{node}\\n'"

hidden: extract the code generating "filtered rev" error for wrapping The goal is to help experimentation in extensions (ie: evolve) around more advance messages.

serve: add support for Mercurial subrepositories I've been using `hg serve --web-conf ...` with a simple '/=projects/**' [paths] configuration for awhile without issue. Let's ditch the need for the manual configuration in this case, and limit the repos served to the actual subrepos. This doesn't attempt to handle the case where a new subrepo appears while the server is running. That could probably be handled with a hook if somebody wants it. But it's such a rare case, it probably doesn't matter for the temporary serves. The main repo is served at '/', just like a repository without subrepos. I'm not sure why the duplicate 'adding ...' lines appear on Linux. They don't appear on Windows (see 594dd384803c), so they are optional. Subrepositories that are configured with '../path' or absolute paths are not cloneable from the server. (They aren't cloneable locally either, unless they also exist at their configured source, perhaps via the share extension.) They are still served, so that they can be browsed, or cloned individually. If we care about that cloning someday, we can probably just add the extra entries to the webconf dictionary. Even if the entries use '../' to escape the root, only the related subrepositories would end up in the dictionary.

hgwebdir: allow a repository to be hosted at "/" This can be useful in general, but will also be useful for hosting subrepos, with the main repo at /.