encoding: define an enum that specifies what normcase does to ASCII strings For C code we don't want to pay the cost of calling into a Python function for the common case of ASCII filenames. However, while on most POSIX platforms we normalize filenames by lowercasing them, on Windows we uppercase them. We define an enum here indicating the direction that filenames should be normalized as. Some platforms (notably Cygwin) have more complicated normalization behavior -- we add a case for that too. In upcoming patches we'll also define a fallback function that is called if the string has non-ASCII bytes. This enum will be replicated in the C code to make foldmaps. There's unfortunately no nice way to avoid that -- we can't have encoding import parsers because of import cycles. One way might be to have parsers import encoding, but accessing Python modules from C code is just awkward. The name 'normcasespecs' was chosen to indicate that this is merely an integer that specifies a behavior, not a function. The name was pluralized since in upcoming patches we'll introduce 'normcasespec' which will be one of these values.

merge with stable

json: implement {help} template We should consider add HTML rendering of the RST into the response as a follow-up. I attempted to do this, but there was an empty array returned by the rstdoc() template function. Not sure what's going on. Will deal with it later.

json: implement {helptopics} template

json: implement {manifest} template Property naming was borrowed from `hg files -Tjson`. We omit branch because, again, representation of branches in this template is wonky.

json: implement {shortlog} and {changelog} templates These are the same dispatch function under the hood. The only difference is the default number of entries to render and the template to use. So it makes sense to use a shared template. Format for {changelistentry} is similar to {changeset}. However, there are differences to argument names and their values preventing us from (easily) using the same template. (Perhaps there is room to consolidate the templates as a follow-up.) We're currently not recording some data in {changelistentry} that exists in {changeset}. This includes the branch name. This should be added in a follow-up. For now, something is better than nothing.

help: populate template functions via docstrings We do this for revsets, template keywrods, and template filters. Now we do it for template functions as well.

templater: add consistent docstrings to functions The content of "hg help templating" is largely derived from docstrings on functions providing functionality. Template functions are the long holdout. Prepare for generating them dynamically by defining docstrings for all template functions. There are numerous ways these docs could be improved. Right now, the help output simply shows function names and arguments. So literally any accurate data is better than what is there now.

changeset_printer: hide manifest node for workingctx Because workingctx has no manifest, it makes sense to hide "manifest:" row completely.

changeset_printer: display p1rev:p1node with "+" suffix for workingctx Still templater can't handle workingctx, which will be fixed later.

changeset_printer: handle workingctx in _meaningful_parentrevs()

scmutil: add function to help handling workingctx in arithmetic operation It's unfortunate that workingctx revision is None, which doesn't work well in arithmetic operation or comparison. This function is trivial but will be used in several places.

tests: handle deleted .hg directory (git 2.2.0 and higher) (issue4585) In git 2.2.0 and higher, removing files and directories is changed: removing an object that does not exist returns success rather than failure. As a result, even though .hg/hgrc does not exist, success is returned and the .hg/ directory is removed. To handle this correctly, use 'rm -rf' to allow successful removing for all git versions. The exact changeset where this was introduced in git: 1054af7d04aef64378d69a0496b45cdbf6a0bef2 wrapper.c: remove/unlink_or_warn: simplify, treat ENOENT as success

hgweb: resurrect <span> tag on diffline to fix rendering in monoblue style It was removed at 606a3bf82e30 as a useless tag, but it is necessary to apply "div.diff pre span" style. http://selenic.com/repo/hg/rev/606a3bf82e30?style=monoblue

merge with stable

encoding: use parsers.asciiupper when available This is used on Windows and Cygwin, and the gains from this are expected to be similar to what was seen in 80f2b63dd83a.

parsers: introduce an asciiupper function

parsers: make _asciilower a generic _asciitransform function We can now pass in whatever table we like. For example, an upcoming patch will introduce asciiupper.

parsers._asciilower: use an explicit return object No functional change, but this will make upcoming patches cleaner.

parsers: factor out most of asciilower into an internal function We're going to reuse this in upcoming patches. The change to Py_ssize_t is necessary because parsers.c doesn't define PY_SSIZE_T_CLEAN. That macro changes the behavior of PyArg_ParseTuple but not PyBytes_GET_SIZE.

manifestv2: add support for writing new manifest format If .hg/requires has 'manifestv2', the manifest will be written using the new format.

manifestv2: add support for reading new manifest format The new manifest format is designed to be smaller, in particular to produce smaller deltas. It stores hashes in binary and puts the hash on a new line (for smaller deltas). It also uses stem compression to save space for long paths. The format has room for metadata, but that's there only for future-proofing. The parser thus accepts any metadata and throws it away. For more information, see http://mercurial.selenic.com/wiki/ManifestV2Plan. The current manifest format doesn't allow an empty filename, so we use an empty filename on the first line to tell a manifest of the new format from the old. Since we still never write manifests in the new format, the added code is unused, but it is tested by test-manifest.py.

manifestv2: set requires at repo creation time While it should be safe to switch to the new manifest format on an existing repo, let's keep it simple for now and make the configuration have any effect only at repo creation time. If the configuration is enabled then (at repo creation), we add an entry to requires and read that instead of the configuration from then on.

test-manifest: extract constants for binary hashes The binary hashes are used quite frequently, so let's extract constants for them so we don't have to repeat binascii.unhexlify() so often.

test-manifest: create constant for empty manifest For symmetry with manifest v2, once we add that, let's extract a constant for the empty v1 manifest.

patchbomb: factor out scmutil.revrange() calls This allows us to access the calculated revs in patchbomb() function.

patchbomb: return outgoing revs as a smartset This helps to factor out scmutil.revrange() calls from _getpatches() and _getoutgoing(). In future patches, a smartset will be passed to _getpatches().

templatefilters: add "upper" and "lower" for case conversion Typically it will be used in patchbomb's flag template, which will be implemented by future patches.