Fri, 06 Apr 2018 17:48:07 -0700 wireproto: port lookup to wire protocol v2
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 06 Apr 2018 17:48:07 -0700] rev 37538
wireproto: port lookup to wire protocol v2 This is pretty straightforward. We don't yet handle errors because we don't have an error handling mechanism in place yet. I'm also tempted to fold this into `known`. We'll come back to this later. Differential Revision: https://phab.mercurial-scm.org/D3205
Fri, 06 Apr 2018 17:39:40 -0700 wireproto: port pushkey command to wire protocol version 2
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 06 Apr 2018 17:39:40 -0700] rev 37537
wireproto: port pushkey command to wire protocol version 2 It doesn't do output redirection yet. And I'd love to generally overhaul the pushkey protocol for wire protocol version 2. But this will be a bit of effort. Let's do it as a follow-up. Differential Revision: https://phab.mercurial-scm.org/D3204
Fri, 06 Apr 2018 17:21:16 -0700 wireproto: only expose "clonebundles" to version 1 transports
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 06 Apr 2018 17:21:16 -0700] rev 37536
wireproto: only expose "clonebundles" to version 1 transports This may make a comeback in wire protocol version 2. The feature definitely needs to be carried forward. But at this juncture, I'm flirting with the idea of implementing this via a "redirect" mechanism at the command response level itself rather than something that requires one-off client support for querying and handling. i.e. I want to make it so servers can say "fetch this first and then come back" and clients handle that automatically. This would not only support clone bundles, but would also support piece-meal "pull bundles." Whatever happens, we can deal with it down the road. Differential Revision: https://phab.mercurial-scm.org/D3203
Fri, 06 Apr 2018 17:14:06 -0700 wireproto: define and expose types of wire command arguments
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 06 Apr 2018 17:14:06 -0700] rev 37535
wireproto: define and expose types of wire command arguments Exposing the set of argument names is cool. But with wire protocol version 2, we're using CBOR to transport arguments and this allows us to have typing for arguments. Typed arguments are much nicer because they will cut down on transfer overhead and processing overhead for decoding values. This commit teaches @wireprotocommand to accept a dictionary for arguments. The arguments registered for version 2 transports are canonically stored as dictionaries rather than a space-delimited string. It is an error to defined arguments with a dictionary for commands using version 1 transports. This reinforces my intent to fully decouple command handlers for version 2 transports. Differential Revision: https://phab.mercurial-scm.org/D3202
Fri, 06 Apr 2018 16:49:57 -0700 wireproto: only expose "stream_out" to version 1 transports
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 06 Apr 2018 16:49:57 -0700] rev 37534
wireproto: only expose "stream_out" to version 1 transports I have plans to implement stream clone using a better mechanism than this existing command. Let's not carry it forward to wire protocol version 2. Differential Revision: https://phab.mercurial-scm.org/D3201
Mon, 09 Apr 2018 11:52:31 -0700 wireproto: implement capabilities for wire protocol v2
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 09 Apr 2018 11:52:31 -0700] rev 37533
wireproto: implement capabilities for wire protocol v2 The capabilities mechanism for wire protocol version 2 represents a clean break from version 1. Instead of effectively exchanging a set of capabilities, we're exchanging a rich data structure. This data structure currently contains information about every available command, including its accepted arguments. It also contains information about supported compression formats. Exposing information about supported commands will allow clients to automatically generate bindings to the server. Clients will be able to do things like detect when they are attempting to run a command that isn't known to the server. Exposing the required permissions to run a command can be used by clients to determine if they have privileges to call a command before actually calling it. We could potentially even have clients send credentials preemptively without waiting for the server to deny the command request. Lots of potential here. The data returned by this command will likely evolve heavily. So we shouldn't bikeshed the implementation just yet. Differential Revision: https://phab.mercurial-scm.org/D3200
Sun, 08 Apr 2018 09:45:45 -0700 context: add deprecation warnings for deprecated types of changeids
Martin von Zweigbergk <martinvonz@google.com> [Sun, 08 Apr 2018 09:45:45 -0700] rev 37532
context: add deprecation warnings for deprecated types of changeids It's close to code freeze, and dropping support for repo['123'] and repo ['my-bookmark'] and repo['deadbeef'] is pretty dispruptive, so this just adds deprecation warnings so extensions can easily find the places they need to fix. Differential Revision: https://phab.mercurial-scm.org/D3197
Sun, 08 Apr 2018 09:28:08 -0700 revsymbol: stop delegating to repo.__getitem__ for unhandled symbols (API)
Martin von Zweigbergk <martinvonz@google.com> [Sun, 08 Apr 2018 09:28:08 -0700] rev 37531
revsymbol: stop delegating to repo.__getitem__ for unhandled symbols (API) The only remaining cases where we were delegating unhandled symbols to repo.__getitem__ should now be when the symbol could not be found. In that case we just delegated to repo.__getitem__ for the error message. Let's just copy the error message instead. If there were any cases where we got e.g. a binary nodeid or an integer revnum into revsymbol() (e.g. via repo.lookup()), we'd now start raising an exception instead. That is why this is marked (API). This affects one test case, but the new behavior seems better to me. I can't tell if the old behavior was desired or if the test was just there to document how it happened to work. Differential Revision: https://phab.mercurial-scm.org/D3196
Sun, 08 Apr 2018 09:28:49 -0700 context: handle partial nodeids in revsymbol()
Martin von Zweigbergk <martinvonz@google.com> [Sun, 08 Apr 2018 09:28:49 -0700] rev 37530
context: handle partial nodeids in revsymbol() Similar reasoning as previous patches. Differential Revision: https://phab.mercurial-scm.org/D3195
Fri, 06 Apr 2018 23:46:17 -0700 context: handle namespaces in revsymbol()
Martin von Zweigbergk <martinvonz@google.com> [Fri, 06 Apr 2018 23:46:17 -0700] rev 37529
context: handle namespaces in revsymbol() Similar reasoning as previous patches. Differential Revision: https://phab.mercurial-scm.org/D3194
Fri, 06 Apr 2018 23:43:52 -0700 scmutil: handle full hex nodeids in revsymbol()
Martin von Zweigbergk <martinvonz@google.com> [Fri, 06 Apr 2018 23:43:52 -0700] rev 37528
scmutil: handle full hex nodeids in revsymbol() This is a bit unfortunate, but it enables moving other pieces out of changectx's constructor without affecting the order in which we look up things (e.g. hex nodeid before bookmark). We convert nodeid to revnum before calling repo.__getitem__, even though that will result in converting back to nodeid later. This is so we can handle the LookupError and attempt to interpret the string as something else (e.g. a bookmark). We also need to start handling WdirUnsupported now, since the full hex nodeid "ffff..." represents the working directory. The exception is raised by the revlog layer. Differential Revision: https://phab.mercurial-scm.org/D3193
Fri, 06 Apr 2018 23:39:40 -0700 context: handle stringified ints in revsymbol()
Martin von Zweigbergk <martinvonz@google.com> [Fri, 06 Apr 2018 23:39:40 -0700] rev 37527
context: handle stringified ints in revsymbol() This patch copies the handling of stringified ints from changectx's constructor. It then calls repo.__getitem__ with the int. Since that method only interprets integers as revnums the first thing it does, this will not be redoing any of the work already done. We leave the old code in place so we can later deprecate it instead of breaking extensions. Differential Revision: https://phab.mercurial-scm.org/D3146
Tue, 10 Apr 2018 19:32:08 +0530 py3: make sure we write bytes to file
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 10 Apr 2018 19:32:08 +0530] rev 37526
py3: make sure we write bytes to file # skip-blame because just b'' prefix Differential Revision: https://phab.mercurial-scm.org/D3220
Tue, 10 Apr 2018 19:21:16 +0530 py3: workaround comparing NoneType and integers
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 10 Apr 2018 19:21:16 +0530] rev 37525
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
Tue, 10 Apr 2018 18:57:56 +0530 py3: use sys.stdout instead of print in test-mq-qpush-fail.t
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 10 Apr 2018 18:57:56 +0530] rev 37524
py3: use sys.stdout instead of print in test-mq-qpush-fail.t Differential Revision: https://phab.mercurial-scm.org/D3218
Tue, 10 Apr 2018 18:57:32 +0530 py3: use '//' for integer division in tests/test-mq-qimport.t
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 10 Apr 2018 18:57:32 +0530] rev 37523
py3: use '//' for integer division in tests/test-mq-qimport.t Differential Revision: https://phab.mercurial-scm.org/D3217
Wed, 11 Apr 2018 14:35:28 +0530 py3: use pycompat.byterepr() instead of repr()
Pulkit Goyal <7895pulkit@gmail.com> [Wed, 11 Apr 2018 14:35:28 +0530] rev 37522
py3: use pycompat.byterepr() instead of repr() Differential Revision: https://phab.mercurial-scm.org/D3216
Tue, 10 Apr 2018 18:56:19 +0530 py3: use bytes instead of str in isinstance()
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 10 Apr 2018 18:56:19 +0530] rev 37521
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
Tue, 10 Apr 2018 18:55:35 +0530 py3: use .startswith() instead of bytes[0]
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 10 Apr 2018 18:55:35 +0530] rev 37520
py3: use .startswith() instead of bytes[0] Differential Revision: https://phab.mercurial-scm.org/D3214
Tue, 10 Apr 2018 20:14:12 +0530 py3: add b'' prefixes in tests/test-ui-config.py
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 10 Apr 2018 20:14:12 +0530] rev 37519
py3: add b'' prefixes in tests/test-ui-config.py # skip-blame because just b'' prefixes Differential Revision: https://phab.mercurial-scm.org/D3221
Sat, 07 Apr 2018 22:22:20 -0400 lfs: infer the blob store URL from paths.default
Matt Harbison <matt_harbison@yahoo.com> [Sat, 07 Apr 2018 22:22:20 -0400] rev 37518
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.
Sat, 07 Apr 2018 22:40:11 -0400 lfs: add the ability to disable the usercache
Matt Harbison <matt_harbison@yahoo.com> [Sat, 07 Apr 2018 22:40:11 -0400] rev 37517
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).
Tue, 10 Apr 2018 22:57:55 -0400 tests: stabilize test-pull-bundle.t for Windows
Matt Harbison <matt_harbison@yahoo.com> [Tue, 10 Apr 2018 22:57:55 -0400] rev 37516
tests: stabilize test-pull-bundle.t for Windows See 594dd384803c.
Sun, 01 Apr 2018 22:41:49 +0900 hgweb: wrap {archives} with mappinglist
Yuya Nishihara <yuya@tcha.org> [Sun, 01 Apr 2018 22:41:49 +0900] rev 37515
hgweb: wrap {archives} with mappinglist No bare list of mappings should be put in a template mapping.
Sun, 01 Apr 2018 22:40:15 +0900 hgweb: forward archivelist() of hgweb to webutil
Yuya Nishihara <yuya@tcha.org> [Sun, 01 Apr 2018 22:40:15 +0900] rev 37514
hgweb: forward archivelist() of hgweb to webutil self.configlist() is ui.configlist(untrusted=True), and url=None in templater effectively means 'url' is undefined.
Sun, 01 Apr 2018 22:37:03 +0900 hgweb: move archivelist() of hgwebdir to webutil
Yuya Nishihara <yuya@tcha.org> [Sun, 01 Apr 2018 22:37:03 +0900] rev 37513
hgweb: move archivelist() of hgwebdir to webutil
Sun, 01 Apr 2018 22:33:55 +0900 hgweb: drop archivespecs from requestcontext
Yuya Nishihara <yuya@tcha.org> [Sun, 01 Apr 2018 22:33:55 +0900] rev 37512
hgweb: drop archivespecs from requestcontext It's a constant.
Sun, 01 Apr 2018 22:32:34 +0900 hgweb: move archivespecs to webutil
Yuya Nishihara <yuya@tcha.org> [Sun, 01 Apr 2018 22:32:34 +0900] rev 37511
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.
Sun, 01 Apr 2018 22:20:44 +0900 hgweb: wrap {labels} by hybridlist()
Yuya Nishihara <yuya@tcha.org> [Sun, 01 Apr 2018 22:20:44 +0900] rev 37510
hgweb: wrap {labels} by hybridlist() This one is a simple list of strings, which can support map operation.
Sun, 01 Apr 2018 22:14:36 +0900 hgweb: wrap {pathdef} with mappinglist
Yuya Nishihara <yuya@tcha.org> [Sun, 01 Apr 2018 22:14:36 +0900] rev 37509
hgweb: wrap {pathdef} with mappinglist No bare list of mappings should be put in a template mapping.
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip