remotenames: add functionality to store remotenames under .hg/hgremotenames/ This patch moves the functionality from remotenames extension to store remotenames to core. Storage format used by remotenames extension: A single file `.hg/remotenames` with an entry in each line where each line is of format: `node nametype remotepath/name` where nametype is either 'bookmarks' or 'branches'. This was not the best way to store data, so while moving to core the storage format was changed but yet not the final format. The storage format used by core after this patch will be: * A file for each type of name i.e. bookmarks and branches in .hg/remotenames/ directory * A version number on the top of the file. The version for current format is 0. * An entry in each line where each line is of the format `node\0remotepath\0name` The logic to sync with existing remotenames file and saving journals and other related things will be moved to core in next patches incrementally. Thanks to Ryan, Augie and Durham for suggestions on storage format. Previously reviewed as D939. Differential Revision: https://phab.mercurial-scm.org/D1548

remotenames: move function to pull remotenames from the remoterepo to core This patch is the first patch of the series moving functionality from hgremotenames extension to core. There are lot of functionality in the extension which in the end enables us to store branch heads and bookmarks location on a server from which we are pulling or cloning from. This will help us in creating a better bookmark workflow where we can show user that a certain server has this bookmarks at this node. It will also introduce namespaces related to remote bookmarks and remote branches. This patch moves the functionality to pull branches and bookmarks from a server from which we are pulling to core behind config option `experimental.remotenames`. This patch adds a test which helps us to analyse whether things are working or not. We are currently writing things to ui, we will write information to files in upcoming patches. Previously reviewed as D937. Differential Revision: https://phab.mercurial-scm.org/D1547

test: fix bad replace for fixing pure-only build When we replaced the patterns, glob was removed on the fixed line, it was a mistake and caused the pure-only build to fails. Differential Revision: https://phab.mercurial-scm.org/D1592

test: fix common-pattern for pure variant The $USUAL_COMPRESSIONS$ value that was taken was not compatible with the pure variant systems as zlib seems to not be available in these case. Differential Revision: https://phab.mercurial-scm.org/D1562

tests: add a substitution for EADDRINUSE/WSAEADDRINUSE messages I suspect some more of these are globbed out, so this is a bit of future proofing.

tests: add a substitution for ECONNRESET/WSAECONNRESET messages

tests: add a substitution for ENOTDIR/ERROR_PATH_NOT_FOUND messages

tests: add a substitution for ENOENT/ERROR_FILE_NOT_FOUND messages Automatic replacement seems better than trying to figure out a check-code rule. I didn't bother looking to see why the error message and file name is reversed in the annotate and histedit tests, based on Windows or not. I originally had this as a list of tuples, conditional on the platform. But there are a couple of 'No such file or directory' messages emitted by Mercurial itself, so unconditional is required for stability. There are also several variants of what I assume is 'connection refused' and 'unknown host' in test-clone.t and test-clonebundles.t for Docker, FreeBSD jails, etc. Yes, these are handled by (re) tags, but maybe it would be better to capture those strings in order to avoid whack-a-mole in future tests. All of this points to using a dictionary containing one or more strings-to-be-replaced values.

setup: only write some autogenerated files if they change Without this change, setup.py always writes some files on every invocation. This prevents some builds from being a no-op when they should. And, since times can sneak into generated .pyc files, this prevents file content from being deterministic between builds. As part of the refactor, we treat file content as bytes. The only potential regression from this would be if some tool is looking at mtimes of the changed files to determine if further action should be taken. But I don't think anything critically important is keyed off the mtimes of these specific files. Differential Revision: https://phab.mercurial-scm.org/D1580

python3: whitelist many more passing tests Differential Revision: https://phab.mercurial-scm.org/D1584