hg-stable: Changelog

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