Kyle Lippincott <spectral@google.com> [Thu, 15 Nov 2018 11:16:42 -0800] rev 40664
changegroup: avoid instantiating storage if we are not using it
Differential Revision: https://phab.mercurial-scm.org/D5280
Matt Harbison <matt_harbison@yahoo.com> [Fri, 16 Nov 2018 17:56:36 -0500] rev 40663
http: allow 'auth.prefix' to have a username consistent with the URI
It may be a little weird to put a username in the prefix, but the documentation
doesn't disallow it, and silently disallowing it has caused confusion[1]. The
username must match what is passed in (which seems to be from the URI via a
circuitous route), as well as 'auth.username' if it was specified. I thought
about printing a warning for a mismatch, but we already don't print a warning if
the 'auth.username' and URI username don't match.
This change allows the first and second last new test cases to work as expected.
It looks like this would have been a problem since at least
0593e8f81c71.
[1] https://www.mercurial-scm.org/pipermail/mercurial/2018-November/051069.html
Matt Harbison <matt_harbison@yahoo.com> [Thu, 15 Nov 2018 18:14:57 -0500] rev 40662
lfs: make the exception messages consistent
I don't love that it repeats 'HTTP Error' in an already long message, but I
doubt that we should assume that it will always say that on the original
exception message.
Matt Harbison <matt_harbison@yahoo.com> [Thu, 15 Nov 2018 18:08:29 -0500] rev 40661
lfs: handle URLErrors to add additional information
Sometimes the blob server is hit first (e.g. on push), and sometimes it's hit
last (e.g. pull). Throw in depth first subrepo operations, and things quickly
get insane. It wasn't even mentioning LFS, so just saying "connection refused"
can be confusing- especially if the blob server is a secondary server and
connecting to the repo server works.
The exception handler for the transfer handler will print the full path to the
blob, but that seems fine given that it might be necessary to debug a second
server. (We don't yet support a standalone blob server, so the handler for the
Batch API will cover 99.9% of the current problems. But it might as well be
handled now while I'm thinking about it.)
The function for translating to a message was mostly borrowed from
scmutil.catchall().
Matt Harbison <matt_harbison@yahoo.com> [Thu, 15 Nov 2018 17:58:59 -0500] rev 40660
lfs: improve the hints for common errors in the Batch API
The previous message was too debug-ish and less action oriented than a hint
should be. The remaining errors that aren't handled are more along the lines of
programming errors (not using POST, bad accept type, etc), so I'm not bothering
with that.
The friendly errors purposely use `self.baseurl` instead of the full Batch API
endpoint because I'd expect some copy/paste/modify on the part of the user here,
and it would be more confusing if '/objects/batch' magically appeared, but
shouldn't be used in the config setting. It still seems like the right thing
for debugging in the catchall case.
Matt Harbison <matt_harbison@yahoo.com> [Thu, 15 Nov 2018 17:55:01 -0500] rev 40659
lfs: provide more Batch API error info via a hint in the raised exception
A coworker had a typo in `lfs.url`, forgot it was even set because usually the
blob server is inferred, and then got a 404. It would have been easier to debug
with the failing URL printed.
Matt Harbison <matt_harbison@yahoo.com> [Thu, 15 Nov 2018 17:50:14 -0500] rev 40658
scmutil: display the optional hint when handling StorageError in catchall()
Other than CensoredNodeError (which is also a StorageError), it looks like all
exceptions with a hint display them. I'm not sure that it makes sense to have a
hint for censored nodes, so I'm not bothering with that.
It looks like nobody is using this yet, as the tests don't change.
Boris Feld <boris.feld@octobus.net> [Thu, 15 Nov 2018 14:57:26 +0100] rev 40657
sparse-revlog: align endrevidx usages in the _slicechunktosize
All "startrevidx..endrevidx" ranges in this function are now half-open.
Yuya Nishihara <yuya@tcha.org> [Thu, 15 Nov 2018 22:59:38 +0900] rev 40656
graft: do not try to skip rev derived from ancestor more than once (
issue6024)
We check 'x in revs' in other cases, so let's do the same.
The test case credits to Tom Prince.
Matt Harbison <matt_harbison@yahoo.com> [Fri, 16 Nov 2018 18:37:26 -0500] rev 40655
subrepo: print the status line before creating the peer for better diagnostics
I ran into a problem where I tried updating to a different branch, and the
process appeared to hang. It turned out that the subrepo revision wasn't
available locally, and I must have originally cloned it from an `hg serve -S` on
a machine that currently wasn't serving anything. It took 2+ minutes to
timeout, and didn't mention what it was connecting to even then.
There are a couple of other issues in this scenario too.
- The repo is dirty after the failed checkout because the top level repo is
updated first. We should probably make 2 passes- top down to pull
everything needed, and then do an update once everything is in place.
- Something must be reading .hgsubstate from wdir because if the same merge
command is run after the timeout, a prompt is issued that the local and
remote subrepo diverged, instead of hanging. But it lists the local version
and remote version as having the same hash.