py3: make sure we write bytes to file # skip-blame because just b'' prefix Differential Revision: https://phab.mercurial-scm.org/D3220

py3: workaround comparing NoneType and integers Comparing None with integers was fine in Python 2 but returns error in Python 3 which is nice. This patch replaces None with -1 where sorting is done and some related logic. Differential Revision: https://phab.mercurial-scm.org/D3219

py3: use sys.stdout instead of print in test-mq-qpush-fail.t Differential Revision: https://phab.mercurial-scm.org/D3218

py3: use '//' for integer division in tests/test-mq-qimport.t Differential Revision: https://phab.mercurial-scm.org/D3217

py3: use pycompat.byterepr() instead of repr() Differential Revision: https://phab.mercurial-scm.org/D3216

py3: use bytes instead of str in isinstance() We deal with bytes internally and things should be bytes Differential Revision: https://phab.mercurial-scm.org/D3215

py3: use .startswith() instead of bytes[0] Differential Revision: https://phab.mercurial-scm.org/D3214

py3: add b'' prefixes in tests/test-ui-config.py # skip-blame because just b'' prefixes Differential Revision: https://phab.mercurial-scm.org/D3221

lfs: infer the blob store URL from paths.default If `lfs.url` is specified, it takes precedence. However, now that we support serving blobs via hgweb, we shouldn't *require* this setting. Less configuration is better (things will work out of the box once this is sorted out), and git has similar functionality. This is not a complete solution- it isn't able to infer the blob store from an explicitly supplied path, and it should consider `paths.default-push` for push. The pull solution for that is a bit hacky, and this alone is an improvement for the vast majority of cases. Even though there are only a handful of references to the saved remote store, the location of them makes things complicated. 1) downloading files on demand in the revlog flag processor 2) copying to readonlyvfs with bundlerepo 3) downloading in the file prefetch hook 4) the canupload()/skipdownload() checks 5) uploading blobs Since revlog doesn't have a repo or ui reference, we can't avoid creating a remote store when the extension is loaded. While the long term goal is to make sure the prefetch hook is invoked early for every command for efficiency, this handling in the flag processor is needed as a last ditch fetch. In order to support the clone command, the remote store needs to be created later than when the extension loads, since `paths.default` isn't set until just before the files are checked out. Therefore, this patch changes the prefetch hook to ignore the saved reference, and build a new one. The canupload()/skipdownload() checks simply check if the stored instance is a `_nullremote`. Since this can only be set via `lfs.url` (which is reflected in the saved reference), checking only the instance created when the extension loaded is fine. The blob uploading function is called from several places: 1) a prepush hook 2) when writing a new bundle 3) from infinitepush The prepush hook gets an exchange.pushop, so it has a path to where the push is going. The bundle writer and infinitepush don't. Further, bundle creation for things like strip and amend are causing blobs to be uploaded. This seems wrong, but I don't want to side track this sorting that out, so punt on trying to handle explicit push paths or `paths.default-push`. I also think that sending blobs to a remote store when pushing to a local repo is wrong. This functionality predates the usercache, so perhaps that's the reason for it. I've got some patches floating around to stop sending blobs remotely in this case, and instead write directly to the other repo's blob store. But the tests for corruption handling weren't happy with this change, and I don't have time to rewrite them. So exclude filesystem based paths from this for now. I don't think there's much of a chance to implement `paths.remote:lfsurl` style configs, given how early these are resolved vs how late the remote store is created. But git has it, so I threw a TODO in there, in case anyone has ideas. I have no idea why this is now doing http auth twice when it wasn't before. I don't think the original blobstore's url is ever being used in these cases.

lfs: add the ability to disable the usercache While the usercache is important for real world uses, I've been tripped up more than a couple of times by it in tests- thinking a file was being downloaded, but it was simply linked from the local cache. The syntax for setting it is the same as for setting a null remote endpoint, and like that endpoint, is left undocumented. This may or may not be a useful feature in the real world (I'd expect any sane filesystem to support hardlinks at this point).

tests: stabilize test-pull-bundle.t for Windows See 594dd384803c.

hgweb: wrap {archives} with mappinglist No bare list of mappings should be put in a template mapping.

hgweb: forward archivelist() of hgweb to webutil self.configlist() is ui.configlist(untrusted=True), and url=None in templater effectively means 'url' is undefined.

hgweb: move archivelist() of hgwebdir to webutil

hgweb: drop archivespecs from requestcontext It's a constant.

hgweb: move archivespecs to webutil Move one step further from e38e7ea21987. Since 'archivespecs' is a constant shared with hgweb and hgwebdir, webutil is a better place to define it.

hgweb: wrap {labels} by hybridlist() This one is a simple list of strings, which can support map operation.

hgweb: wrap {pathdef} with mappinglist No bare list of mappings should be put in a template mapping.

hgwebdir: wrap {entries} with mappinggenerator No bare generator should be put in a template mapping.

eol: look up partial nodeid as partial nodeid Similar reasoning as the previous patch. For some reason the hook gives us a partial nodeid, so we need to resolve that to a full nodeid. Differential Revision: https://phab.mercurial-scm.org/D3159

histedit: look up partial nodeid as partial nodeid I'm about to remove support for repo[<partial hex nodeid>]. In the verify() method, we know that self.node is always a partial or full binary nodeid, so the most correct way to look up the revision is by using changelog._partialmatch(), so let's do that. (It's closer to the current code to do scmutil.revsymbol(), but that's less correct because it will match a bookmark or tag that happens to have the same prefix as the node.) Differential Revision: https://phab.mercurial-scm.org/D3158

histedit: drop unnecessary check for "self.node is not None" We are doing hex(self.node) just a few lines up, so it shouldn't be None. The only way it could be none is if it was reassigned in between. The only way that can happen is if the user had put a "ffff..." wdirhex revision in the histedit script. This code is much older than the "ffff..." identifier, so I'm confident it's not there to handle that case. I'll let someone else add proper checks for "ffff..." if they care enough. Differential Revision: https://phab.mercurial-scm.org/D3157

context: extract partial nodeid lookup method to scmutil We will add another caller soon, and there's a non-obvious reason to use the unfiltered repo that we don't want to copy across the code base. Differential Revision: https://phab.mercurial-scm.org/D3189

templatekw: fix return type of {succsandmarkers} (BC) A hybrid object represents a list/dict of values, but {succsandmarkers} returns a list of template mappings. This change means old-style list templates (e.g. "start_succsandmarkers") are no longer supported, but that should be okay since {succsandmarkers} is still experimental and relatively new.

formatter: remove template resources from nested items before generating JSON

templater: add public interface returning a set of resource keys The next patch depends on knownresourcekeys(), and there's no reason to keep availableresourcekeys() private.

formatter: make nested items somewhat readable in template output

templater: wrap result of '%' operation so it never looks like a thunk This fixes min/max()/json() of map result. Before, it was taken as a lazy byte string and stringified by evalfuncarg().

wireproto: support for pullbundles Pullbundles are similar to clonebundles, but served as normal inline bundle streams. They are almost transparent to the client -- the only visible effect is that the client might get less changes than what it asked for, i.e. not all requested head revisions are provided. The client announces support for the necessary retries with the partial-pull capability. After receiving a partial bundle, it updates the set of revisions shared with the server and drops all now-known heads from the request list. It will then rerun getbundle until no changes are received or all remote heads are present. Extend badserverext to support per-socket limit, i.e. don't assume that the same limits should be applied to all sockets. Differential Revision: https://phab.mercurial-scm.org/D1856

filelog: wrap revlog instead of inheriting it (API) The revlog base class exposes a ton of methods. Inheriting the revlog class for filelog will make it difficult to expose a clean interface. There will be abstraction violations. This commit breaks the inheritance of revlog by the filelog class. Filelog instances now contain a reference to a revlog instance. Various properties and methods are now proxied to that instance. There is precedence for doing this: manifestlog does something similar. Although, manifestlog has a cleaner interface than filelog. We'll get there with filelog... The new filelog class exposes a handful of extra properties and methods that aren't part of the declared filelog interface. Every extra item was added in order to get a test to pass. The set of tests that failed without these extra proxies has significant overlap with the set of tests that don't work with the simple store repo. There should be no surprise there. Hopefully the hardest part about this commit to review are the changes to bundlerepo and unionrepo. Both repository types define a custom revlog or revlog-like class and then have a custom filelog that inherits from both filelog and their custom revlog. This code has been changed so the filelog types don't inherit from revlog. Instead, they replace the revlog instance on the created filelog. This is super hacky. I plan to fix this in a future commit by parameterizing filelog.__init__. Because Python function call overhead is a thing, this change could impact performance by introducing a nearly empty proxy function for various methods and properties. I would gladly measure the performance impact of it, but I'm not sure what operations have tight loops over filelog attribute lookups or function calls. I know some of the DAG traversal code can be sensitive about the performance of e.g. parentrevs(). However, many of these functions are implemented on the revlog class and therefore have direct access to self.parentrevs() and aren't going through a proxy. .. api:: filelog.filelog is now a standalone class and doesn't inherit from revlog. Instead, it wraps a revlog instance at self._revlog. This change was made in an attempt to formalize storage APIs and prevent revlog implementation details leaking through to callers. Differential Revision: https://phab.mercurial-scm.org/D3154

util: drop write_content_size=True This is now the default in python-zstandard 0.9. While we're here, also add a comment about the ability to drop frame magic to save space. Differential Revision: https://phab.mercurial-scm.org/D3199

zstandard: vendor python-zstandard 0.9.0 This was just released. It features a number of goodies. More info at https://gregoryszorc.com/blog/2018/04/09/release-of-python-zstandard-0.9/. The clang-format ignore list was updated to reflect the new source of files. The project contains a vendored copy of zstandard 1.3.4. The old version was 1.1.3. One of the changes between those versions is that zstandard is now dual licensed BSD + GPLv2 and the patent rights grant has been removed. Good riddance. The API should be backwards compatible. So no changes in core should be needed. However, there were a number of changes in the library that we'll want to adapt to. Those will be addressed in subsequent commits. Differential Revision: https://phab.mercurial-scm.org/D3198

revlog: reset _nodepos after strip When using the pure revlog parser, _nodepos is used to keep track of the position during index scanning in the non-cached cache. If it is out of bounds, BaseIndexObject._fix_index will assert. Since strip can actually remove the position scanned last, make sure to reset it. Add an assertion in the place where the invariance is clearer. Differential Revision: https://phab.mercurial-scm.org/D3188

paper: make all source lines have the same minimum height Empty source lines in paper and coal themes used to have smaller height than every other line (because of the way line numbers are shown and because they are using smaller font). This wasn't very noticeable before the follow lines functionality was added, but after that just using the follow-lines button to select a block of code with empty lines would demonstrate the fact that empty lines didn't have enough height - there were white "gaps" in the selection block. Since this problem occurs when lines don't have any content inside, let's create a pseudo-element (it's unselectable because of that) which still doesn't have any content, but fills up empty lines to 100% of their height because of display: inline-block. This is the most natural way to solve this annoyance that I've found so far. Hardcoding height isn't useful because we can have wrapped lines, in which case multiple lines of text need to fit into a single <span>. Setting min-height or line-height doesn't remove the gaps when viewed in Chromium.

hgweb: make followlines button absolutely positioned It used to have position: absolute only on annotate page, but it makes sense to have it everywhere, because the button shouldn't affect other elements at all. Especially since the button has a set height, which meant that for certain smaller fonts source lines were changing their height on hover. Note that the button doesn't set any of the usual properties that accompany absolute position (top, right, bottom or left). These properties would position the button without any account for source line padding. Instead, margins are used (the button already has all margins defined, they do the job).

hgweb: insert followlines buttons before any children, including text nodes This way the buttons come before any other content, including text nodes. Because highlight extension replaces every line of text with some <span> elements that have CSS classes for highlighting, the placement of followlines buttons used to depend on if that extension was enabled or not. Let's make the placement more consistent, it'll help the next patch in this series.

wireproto: only expose "debugwireargs" to version 1 transports I'm not even sure this command should be enabled for version 1 transports. It is just a reflection endpoint for argument data. We definitely don't need to support it in version 2. Differential Revision: https://phab.mercurial-scm.org/D3184

wireproto: only expose "hello" command to version 1 transports This command is only ever used for the handshake in the SSH protocol. We probably don't even need for it to be a proper command. Let's not carry it forward to version 2 because I don't see a use for it there. Differential Revision: https://phab.mercurial-scm.org/D3183

wireproto: port branchmap to wire protocol v2 Differential Revision: https://phab.mercurial-scm.org/D3182

wireproto: port listkeys commands to wire protocol v2 Differential Revision: https://phab.mercurial-scm.org/D3181

wireproto: port keep command to wire protocol v2 This is pretty straightforward. Differential Revision: https://phab.mercurial-scm.org/D3180

wireproto: port heads command to wire protocol v2 After much thought and consideration, wire protocol version 2's commands will be defined in different functions from the existing commands. This will make it easier to implement these commands because it won't require shoehorning things like response formatting and argument declaration into the same APIs. For example, wire protocol version 1 requires that commands declare a fixed and ordered list of argument names. It isn't really possible to insert new arguments or have optional arguments without breaking backwards compatibility. Wire protocol version 2, however, uses CBOR maps for passing arguments. So arguments a) can be optional b) can be added without BC c) can be strongly typed. This commit starts our trek towards reimplementing the wire protocol for version 2 with the heads command. It is pretty similar to the existing heads command. One added feature is it can be told to operate on only public phase changesets. This is useful for making discovery faster when a repo has tens of thousands of draft phase heads (such as Mozilla's "try" repository). The HTTPv2 server-side protocol has had its `getargs()` implementation updated to reflect that arguments are a map and not a list. Differential Revision: https://phab.mercurial-scm.org/D3179

largefiles: wrap heads command handler more directly extensions.wrapfunction() is a more robust method for wrapping a function, since it allows multiple wrappers. While we're here, wrap the function registered with the command instead of installing a new command handler. Differential Revision: https://phab.mercurial-scm.org/D3178

wireproto: crude support for version 2 HTTP peer As part of implementing the server-side bits of the wire protocol command handlers for version 2, we want a way to easily test those commands. Currently, we use the "httprequest" action of `hg debugwireproto`. But this requires explicitly specifying the HTTP request headers, low-level frame details, and the data structure to encode with CBOR. That's a lot of boilerplate and a lot of it can change as the wire protocol evolves. `hg debugwireproto` has a mechanism to issue commands via the peer interface. That is *much* easier to use and we prefer to test with that going forward. This commit implements enough parts of the peer API to send basic requests via the HTTP version 2 transport. The peer code is super hacky. Again, the goal is to facilitate server testing, not robustly implement a client. The client code will receive love at a later time. Differential Revision: https://phab.mercurial-scm.org/D3177

tests: extract wire protocol shell helpers to standalone file This will make it easier for other tests to get up and running without the boilerplate. Differential Revision: https://phab.mercurial-scm.org/D3176

addbranchrevs: no longer accept revset as "revs" (API) The only caller was removed in 0b4692b9646d (bundle: avoid repo.lookup() for converting revnum to nodeid, 2018-04-02). Differential Revision: https://phab.mercurial-scm.org/D3192

clone: avoid using repo.lookup() with binary nodeid The code in hg.clone() is a bit of a mess, but it seems like the "checkout" variable is always a binary nodeid (tests pass when run with "assert len(checkout) == 20" before the repo.lookup()). repo.lookup() will soon work only with string inputs, so we need remove this use. Differential Revision: https://phab.mercurial-scm.org/D3191

merge: avoid unnecessary conversion from binary nodeid to binary nodeid "node" is already a binary nodeid here, so there's no need to convert it. repo.lookup() will soon lose support for binary nodeids as input. Differential Revision: https://phab.mercurial-scm.org/D3190

tests: stabilize test-push-http.t for Windows See 594dd384803c.

tests: add a substitution pattern for HTTP error log dates This will make tests with error log content less of a nuisance. I didn't roll it into to $LOGDATE$ because the regex got long and line wrapped. It didn't seem worth the obscurity.

wireproto: convert python literal to object without using unsafe eval() Follows up cc5a040fe150. At this point, I don't think we need a real eval(). If we want to support a set literal, maybe we can vendor ast.literal_eval(), which is relatively simple function.

tests: quote variable passed to shell test command

py3: system-stringify repr(frame) That's the Py3 requirement.

wireproto: show unknown id and flags in repr(frame) Perhaps we'll want it for debugging.

wireproto: fix repr(frame) to not crash by unknown type id Follows up 5ef2da00e935.

py3: use s.startswith() instead of s[n] while parsing patches I know 'bytes[n] in bytes' magically works, but I'm tired of finding which one breaks the tests.

py3: do not try to byte-stringify None in cmdutil.tryimportone() It's a debug message, so just use '' instead.

py3: work around weird handling of bytes/unicode in decode_header() Basically decode_header() works as follows, and on Python 3, email headers ARE UNICODE. def decode_header(header): if not ecre.search(header): # ecre is unicode regexp return [(header, None)] # so header is unicode string ... decode header into [(bytes_data, unicode_charset_name)] return collapsed

py3: use system string to access email headers

py3: fix string issues of email message in test-import.t - payload can be bytes - headers must be unicode on Python 3 - need to call msg.as_bytes() on Python 3, but msg.as_string() on Python 2, where bytes(msg) magic works

py3: use lower-cased module 'email.message' in test-import.t

py3: drop b'' from error message of fancyopts

procutil: drop unused 'newlines' option from popen*() (API) It's unlikely for us to use the universal_newlines option.

procutil: make explainexit() simply return a message (API) Almost all callers want it.

procutil: do not convert return code of signal exit to positive number (API) The docstring states that "codes from kill are negative", and it doesn't make sense to make exit/signal code ambiguous. .. api:: ``hook.hook()`` and ``hook.runhooks()`` may return a negative integer to denote that the process was killed by signal.

procutil: fix error message of tempfile filter First, we need to use procutil.system() to get an exit code compatible with explainexit(). Second, explainexit() returns (msg, code) tuple.

procutil: unify platform.explainexit() Since 4368f582c806 "use subprocess instead of os.system", posix.explainexit() is the superset of Windows implementation.

procutil: rewrite popen() as a subprocess.Popen wrapper (issue4746) (API) os.popen() of Python 3 is not the popen() we want. First, it doesn't accept command in bytes. Second, a returned stream is always wrapped by TextIO. So we have to reimplement our popen(). Fortunately, this fixes the bug 4746 since ours returns an exit code compatible with explainexit(). .. api:: ``procutil.popen()`` no longer supports text mode I/O.

procutil: always popen() in binary mode On Python 3, non-binary stream is useless. Let's convert line ending by ourselves. Note that we don't need fromnativeeol() in patch._externalpatch() since any whitespace characters are rstrip()-ed.

py3: byte-stringify test-import.t Still the test doesn't pass. # skip-blame because just adding some b''

py3: convert parsed message items to bytes in patch.extract() Appears that BytesParser() parses bytes into unicode, sigh.

py3: silence warning about deprecation of imp module Well, we could fix that, but we aren't yet to reach the state caring about deprecation on the Python 3 line. So let's silence it for now to fix tons of "minor" Py2/3 incompatibilities by relying on our test suite.

tests: add another full hex node in plain text Should have been part of D3168. Differential Revision: https://phab.mercurial-scm.org/D3186

infinitepush: look up bookmarks only among bookmarks Differential Revision: https://phab.mercurial-scm.org/D3165

destutil: look up bookmarks only among bookmarks Differential Revision: https://phab.mercurial-scm.org/D3164

discovery: look up bookmarks only among bookmarks Differential Revision: https://phab.mercurial-scm.org/D3163

bookmarks: introduce a repo._bookmarks.changectx(mark) method and use it Many places were doing repo[mark], which usually works, but it's slightly incorrect: if the bookmark has a name that matches a full hex nodeid of another node, then the context for the other node will be returned instead. Also, I'm about to remove support for repo[<namespace thing>] :) Differential Revision: https://phab.mercurial-scm.org/D3162

revlog: detect pseudo file nodeids to raise WdirUnsupported exception Again, I'm not sure if this is the right thing, but adding a few more pseudo hashes wouldn't be any worse than the current state. Differential Revision: https://phab.mercurial-scm.org/D2942

node: rename wdirnodes to clarify they are for manifest/filelogs Differential Revision: https://phab.mercurial-scm.org/D2941

workingctx: build _manifest on filenode() or flags() request I'm not sure if this is the best workaround, but this fixes the following exception: AttributeError: 'workingctx' object has no attribute '_manifestdelta' The short hash '303030303030' seen in the test is node.modifiednodeid. Differential Revision: https://phab.mercurial-scm.org/D2940

tests: enter full hex hash in plain text in bundle part We were looking it up be prefix by repo.__getitem__, which I'm about to drop support for. It's easiest to just include the full hash in plain text. Differential Revision: https://phab.mercurial-scm.org/D3168

tests: call rawsize() directly rawsize() is not reimplemented outside of revlog. I'm not sure why this code was insisting it call a specific implementation. Changing it to call rawsize() on the repo.file(f) result seems to work just fine. Differential Revision: https://phab.mercurial-scm.org/D3153

upgrade: sniff for filelog type The upgrade code should never encounter a vanilla revlog instance: only changelog, manifestrevlog, and filelog should be seen. The previous code assumed !changelog & !manifestrevlog meant file data. So this change feels pretty safe. If nothing else, it will help tease out typing issues. Differential Revision: https://phab.mercurial-scm.org/D3152

revlog: move censor logic into main revlog class Previously, the revlog class implemented dummy methods for various censor-related functionality. Revision censoring was (and will continue to be) only possible on filelog instances. So filelog implemented these methods to perform something reasonable. A problem with implementing censoring on filelog is that it assumes filelog is a revlog. Upcoming work to formalize the filelog interface will make this not true. Furthermore, the censoring logic is security-sensitive. I think action-at-a-distance with custom implementation of core revlog APIs in derived classes is a bit dangerous. I think at a minimum the censor logic should live in revlog.py. I was tempted to created a "censored revlog" class that basically pulled these methods out of filelog. But, I wasn't a huge fan of overriding core methods in child classes. A reason to do that would be performance. However, the censoring code only comes into play when: * hash verification fails * delta generation * applying deltas from changegroups The new code is conditional on an instance attribute. So the overhead for running the censored code when the revlog isn't censorable is an attribute lookup. All of these operations are at least a magnitude slower than a Python attribute lookup. So there shouldn't be a performance concern. Differential Revision: https://phab.mercurial-scm.org/D3151

revlog: move parsemeta() and packmeta() from filelog (API) filelog.parsemeta() and filelog.packmeta() are used to decode and encode metadata for file copies and censor. An upcoming commit will move the core logic for censoring revlogs into revlog.py. This would create a cycle between revlog.py and filelog.py. So we move these metadata functions to revlog.py. .. api:: filelog.parsemeta() and filelog.packmeta() have been moved to the revlog module. Differential Revision: https://phab.mercurial-scm.org/D3150

filelog: declare that filelog implements a storage interface Now that we have a declared interface, let's declare that filelog implements it. Tests have been added that confirm the object conforms to the interface. The existing interface checks verify there are no extra public attributes outside the declared interface. filelog has several extra attributes. So we added a mechanism to suppress this check. The goal is to modify the filelog class so we can drop this check. Differential Revision: https://phab.mercurial-scm.org/D3149

repository: define existing interface for file storage Now that we have mostly successfully implemented an alternate storage backend for files data, let's start to define the interface for it! This commit takes the mostly-working interface as defined by the simple store repo and codifies it as the file storage interface. The interface has been split into its logical components: * index metadata * fulltext data * mutation * everything else I don't consider the existing interface to be great. But it will help to have it more formally defined so we can start chipping away at refactoring it. Differential Revision: https://phab.mercurial-scm.org/D3148

tests: run some largefiles and lfs tests with simple store Now that the simple store handles flags properly, a handful of the largefiles and lfs tests pass! Differential Revision: https://phab.mercurial-scm.org/D3147

commands: don't violate storage abstractions in `manifest --all` Previously, we asked the store to emit its data files. For modern repos, this would use fncache to resolve the set of files then would stat() each file. For my copy of the mozilla-unified repository, this took 3.3-10s depending on the state of my filesystem cache to render 449,790 items. The previous behavior was a massive layering violation because it assumed tracked files would have specific filenames in specific directories. Alternate storage backends would violate this assumption. The new behavior scans the changelog entries for the set of files changed by each commit. It aggregates them into a set and then sorts and prints the result. This reliably takes ~16.3s on my machine. ~80% of the time is spent in zlib decompression. The performance regression is unfortunate. If we want to claw it back, we can create a proper storage API to query for the set of tracked files. I'm not opposed to doing that. But I'm in no hurry because I suspect ~0 people care about the performance of `hg manifest --all`. .. perf:: `hg manifest --all` is likely slower due to changing its implementation to respect storage interface boundaries. If you are impacted by this regression in a meaningful way, please make noise on the development mailing list and it can be dealt with. Differential Revision: https://phab.mercurial-scm.org/D3119

commands: document the layering violation in `manifest --all` This commit fixes the last test failures when using the simple store extension! It turns out that `hg manifest --all` locks the repo and scans for revlogs. This feature was added by 71938479eff9 in 2011. I am debating changing the behavior. But that can occur in another commit. As part of debugging this, I realized that test-manifest.t is the only meaningful tester of `hg manifest --all` and that test was improperly disabled when bundlerepos aren't supported. The test is testing manifest behavior, not whether you can `hg pull` from a bundle. So I changed the test to `hg unbundle` instead. FWIW, I wasted a non-trivial amount of time tracking down this failure. I thought the issue involved Git, which is why I refactored the test to be more deterministic. Never in my mind would I have guessed that code in `hg manifest` would scan revlogs. I should have looked there to begin with. Doh. Differential Revision: https://phab.mercurial-scm.org/D3118

simplestore: correctly implement flag processors There were a couple of bugs around the implementation of flags processing with the simple store. After these changes, test-flagprocessor.t now passes! test-flagprocessor.t was also updated to include explicit test coverage that pushed data is as expected on the server. The test extension used by test-flagprocessor.t has been updated so it monkeypatches the object returned from repo.file() instead of monkeypatching filelog.filelog. This allows it to work with extensions that return custom types from repo.file(). The monkeypatching is rather hacky and probably is performance prohibitive for real repos. We should probably come up with a better mechanism for registering flag processors so monkeypatching isn't needed. Differential Revision: https://phab.mercurial-scm.org/D3116

tests: `hg init` after resetting HGRCPATH Otherwise extensions loaded via --extra-config-opt could prevent access to the repo by introducing requirements file. This does mean that custom extensions loaded in this way won't impact this test. I'm fine with that. Differential Revision: https://phab.mercurial-scm.org/D3115

tests: work around potential repo incompatibility test-run-tests.t invokes run-tests.py. But custom extensions providing new repo requirements may be in play and may not get inherited by the new run-tests.py. We ensure our repo is created with a vanilla config to mitigate extension-caused badness. Differential Revision: https://phab.mercurial-scm.org/D3114

tests: disable test-keyword.t with simple store The keyword extension is hooking into repo.file() and defining its own filelog class. It will likely require a more formal storage interface before keywords are usable with alternate storage backends. Differential Revision: https://phab.mercurial-scm.org/D3113

tests: conditionalize test-treemanifest.t Parts of the test were assuming the use of revlogs with fnstore path encoding. Other parts of the test assumed we could create repos with different store encodings and that stream clone bundles worked. Make all of this conditional on running a revlog repo. Differential Revision: https://phab.mercurial-scm.org/D3112

tests: use unbundle in test-symlink-os-yes-fs-no.py The test (which should probably be rewritten as a .t test - the test was initially authored in 2009 and this may have predated some test harness features allowing us to implement it as a .t test) is verifying symlink behavior with regards to working directory operations. How it pulls bundle data into a repo is not relevant. So we can switch from pull to unbundle so we can support environments where bundlerepos don't work. Differential Revision: https://phab.mercurial-scm.org/D3111