Matt Harbison <matt_harbison@yahoo.com> [Mon, 04 Dec 2017 21:41:04 -0500] rev 35479
lfs: narrow the exceptions that trigger a transfer retry
The retries were added to workaround TCP RESETs in fb-experimental fc8c131314a9.
I have no idea if that's been debugged yet, but this wide net caught local I/O
errors, bad hostnames and other things that shouldn't be retried. The next
patch will validate objects as they are uploaded, and there's no need to retry
those errors.
The spec[1] does mention that certain http errors can be retried, including 500.
But let's work through the corruption detection issues first.
[1] https://github.com/git-lfs/git-lfs/blob/master/docs/api/batch.md
Matt Harbison <matt_harbison@yahoo.com> [Thu, 16 Nov 2017 22:52:53 -0500] rev 35478
test-lfs: add tests around corrupted lfs objects
These are mostly tests against file:// based remote stores, because that's what
we have the most control over.
The test uploading a corrupt blob to lfs-test-server demonstrates an overly
broad exception handler in the retry loop. A corrupt blob is actually
transferred in a download, but eventually caught when it is accessed (only after
it leaves the corrupt file in a couple places locally). I don't think we want
to trust random 3rd party implementations, and this would be a problem if there
were a `debuglfsdownload` command that simply cached the files. And given the
cryptic errors, we should probably validate the file hash locally before
uploading, and also after downloading.
Matt Harbison <matt_harbison@yahoo.com> [Tue, 19 Dec 2017 17:53:44 -0500] rev 35477
lfs: add note messages indicating what store holds the lfs blob
The following corruption related patches were written prior to adding the user
level cache, and it took awhile to track down why the tests changed. (It
generally made things more resilient.) But I think this will be useful to the
end user as well. I didn't make it --debug level, because there can be a ton of
info coming out of clone/push/pull --debug. The pointers are sorted for test
stability.
I opted for ui.note() instead of checking ui.verbose and then using ui.write()
for convenience, but I see most of this extension does the latter. I have no
idea what the preferred form is.
Matt Harbison <matt_harbison@yahoo.com> [Wed, 20 Dec 2017 20:46:33 -0500] rev 35476
tests: teach `f` to handle sha256 checksums