py3: use string for "close" value in commit extras The extras dict on commits has string keys and values. Before this commit, we passed "close" as an integer, which Python 2 gladly coerced to a string during a %s formatting in the bowels of changelog.py. Differential Revision: https://phab.mercurial-scm.org/D2157

py3: catch TypeError during template operations Two places in this code Python 3 changed from raising ValueError to TypeError. So catch the addition exceptions. IMO this code might be better off performing type sniffing. But I'm not sure the implications of changing that. Differential Revision: https://phab.mercurial-scm.org/D2156

py3: use bytes literals for test extension These extensions don't get run through our custom module importer. It's easy enough to make them dual compatible with Python 2 and 3. # skip-blame b prefixes Differential Revision: https://phab.mercurial-scm.org/D2155

py3: use system strings when calling __import__ We must pass the native str type when importing. Differential Revision: https://phab.mercurial-scm.org/D2154

py3: open patches.queue in binary mode And switch to using the context manager form of open() while we're here. Differential Revision: https://phab.mercurial-scm.org/D2153

py3: compare against bytes instead of str Differential Revision: https://phab.mercurial-scm.org/D2152

py3: use b'' in mockblackbox.py This unmasks a ton of other TypeError in blackbox code. # skip-blame since it's just a b prefix Differential Revision: https://phab.mercurial-scm.org/D2175

narrow: add a TODO document These are things that are bigger than we want to handle right now, but are pretty important to get narrowing to be non-experimental. Differential Revision: https://phab.mercurial-scm.org/D2196

tests: use `hello` not `capabilities` over ssh Differential Revision: https://phab.mercurial-scm.org/D2195

narrowwirepeer: add TODO about how we add wireproto args to unbundle :( Differential Revision: https://phab.mercurial-scm.org/D2194

narrowwirepeer: rename expandnarrow capability to exp-expandnarrow The expandnarrow functionality lets a client have a shorthand (for Google it's a reference to a checked-in file) for a set of includes and excludes. For testing we should probably implement a simple version of that functionality here. For now, rename the capability so we don't burn the good name in the future if we need to change behavior. It's plausible that this functionality should be dropped from the narrowhg we ship long-term, but I'm dubious as it seems pretty likely other organizations will want similar shorthands for commonly-used subsets of their trees. Differential Revision: https://phab.mercurial-scm.org/D2193

narrow: make restrictpatterns a little more idiomatic I'm not sure why invalid_includes was an out-param, but it doesn't look like there's any reason for it to be now. Differential Revision: https://phab.mercurial-scm.org/D2192

narrowspec: consistently use set() to copy sets Differential Revision: https://phab.mercurial-scm.org/D2191

narrowspec: document constraints when validating patterns Differential Revision: https://phab.mercurial-scm.org/D2190

narrowrevlog: add a TODO around remotefilelog moving to core We should clean this up considerably when remotefilelog lands, which we expect to try and accomplish in the near-ish future. Differential Revision: https://phab.mercurial-scm.org/D2189

narrowrevlog: add what little I can remember about rename filtering Differential Revision: https://phab.mercurial-scm.org/D2188

manifest: clean up dirlog() to take a d parameter to avoid shadowing dir() Differential Revision: https://phab.mercurial-scm.org/D2187

narrowrevlog: replace AssertionError with ProgrammingError Differential Revision: https://phab.mercurial-scm.org/D2186

narrowrevlog: document excludeddir class and friends Differential Revision: https://phab.mercurial-scm.org/D2185

narrowrepo: add docstring for narrowpats Differential Revision: https://phab.mercurial-scm.org/D2184

narrowtemplates: update to use registrar mechanism It's worth considering at this point if we should just move the two ellipsis functions to core tagged experimental or something, since they're not really narrowing-specific... Differential Revision: https://phab.mercurial-scm.org/D2009

narrow: move from ELLIPSIS_NODE_FLAG to revlog.REVIDX_ELLIPSIS We should have been using this value all along. Sigh. Differential Revision: https://phab.mercurial-scm.org/D2008

narrowrepo: make repo requirement include the string 'experimental' We can just move to "narrow" or similar when we finalize the format. I'm not sure what the migration process from one requirement to another should look like, but we're about to cross that bridge at Google once this change lands, so hopefully we'll know soon. Differential Revision: https://phab.mercurial-scm.org/D2007

narrow: mark requirement as a constant Differential Revision: https://phab.mercurial-scm.org/D2006

narrowbundle2: mark most constants as module-private This became obvious when preparing the previous change, so there's no reason to not just do it now while it's easy. Differential Revision: https://phab.mercurial-scm.org/D2005

narrowbundle2: make constants ALLCAPS to be a bit more readable Differential Revision: https://phab.mercurial-scm.org/D2004

narrow: remove old version-checking logic and declare internal Differential Revision: https://phab.mercurial-scm.org/D1980

tests: fold narrow treemanifest tests into main test file using testcases These tests predate the testcases functionality in run-tests.py, so it was never done in narrowhg. Differential Revision: https://phab.mercurial-scm.org/D1979

narrow: assume addflagprocessor will always exist on revlog module Differential Revision: https://phab.mercurial-scm.org/D1978

narrow: this code should assume REVIDX_FLAGS_ORDER exists Differential Revision: https://phab.mercurial-scm.org/D1977