mq: use cmdutil.revert instead of hg.revert It's the last user.

debugmergestate: add support for printing out driver-resolved files

debugmergestate: add support for printing out merge driver

merge.mergedriver: don't try resolving files marked driver-resolved The driver is expected to take care of these.

merge.mergestate: add support for persisting driver-resolved files A driver-resolved file is a file that's handled specially by the driver. A common use case for this state would be autogenerated files, the generation of which should happen only after all source conflicts are resolved. This is done with an uppercase letter because older versions of Mercurial will not know how to treat such files at all.

merge.mergestate: add support for persisting a custom merge driver A 'merge driver' is a coordinator for the overall merge process. It will be able to control: - tools for individual files, much like the merge-patterns configuration does today - tools that can work across groups of files - the ordering of file resolution - resolution of automatically generated files - adding and removing additional files to and from the dirstate Since it is a critical part of the merge process, it really is part of the merge state. This is a lowercase character (i.e. optional) because ignoring this is fine for older versions of Mercurial -- however, if there are any files that are specially treated by the driver, we should abort. That will happen in upcoming patches. There is a potential security issue with storing the merge driver in the merge state. See the inline comments for more details.

exchange: support sorting URLs by client-side preferences Not all bundles are appropriate for all clients. For example, someone with a slow Internet connection may want to prefer bz2 bundles over gzip bundles because they are smaller and don't take as long to transfer. This is information that a server cannot know on its own. So, we invent a mechanism for "preferring" server-advertised URLs based on their attributes. We could invent a negotiation between client and server where the client sends its preferences and the sorting/filtering is done server-side. However, this feels complex. We can avoid complicating the wire protocol and exposing ourselves to backwards compatible concerns by performing the sorting locally. This patch defines a new config option for expressing preferred attributes in server-advertised bundles. At Mozilla, we leverage this feature so clients in fast data centers prefer uncompressed bundles. (We advertise gzip bundles first because that is a reasonable default.) I consider this an advanced feature. I'm on the fence as to whether it should be documented in `hg help config`.

exchange: extract bundle specification components into own attributes An upcoming patch will enable clients to prefer certain bundles over others. The idea is that we define values of attributes from manifests that are desirable. The BUNDLESPEC attribute is a complex value consisting of multiple parts. Clients may wish to only prefer one of these parts. Having to specify every combination of BUNDLESPEC would be annoying. So, we extract the components of BUNDLESPEC into their own attributes so clients can easily filter on a sub-component.

exchange: support preserving external names when parsing bundle specs This will be needed to make client-side preferences work easier.

clonebundles: filter on SNI requirement Server Name Indication (SNI) is commonly used in CDNs and other hosted environments. Unfortunately, Python <2.7.9 does not support SNI and when these older Python versions attempt to negotiate TLS to an SNI server, they raise an opaque error like "_ssl.c:507: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure." We introduce a manifest attribute to denote the URL requires SNI and have clients without SNI support filter these entries.