Xavier Deguillard 3a97764d70 revisionstore: add a new StoreResult type ... Summary: When using LFS, it's possible that a pointer may be present in the local LfsStore, but the blob would only be in the shared one. Such scenario can happen after an upload, when the blob is moved to the shared store for instance. In this case, during a `get` call, the local LFS store won't be able to find the blob and thus would return Ok(None), the shared LFS store woud not be able to find the pointer itself and would thus return Ok(None) too. If the server is not aware of the file node itself, the `ContentStore::get` would also return Ok(None), even though all the information is present locally. The main reason why this is happening is due to the `get` call operating primarily on file node based keys, and for content-based stores (like LFS), this means that the translation layer needs to be present in the same store, which in some case may not be the case. By allowing stores to return a `StoreKey` when progress was made in finding the key we can effectively solve the problem described above, the local store would translate the file node key onto a content key, and the shared store would read the blob properly. Reviewed By: DurhamG Differential Revision: D22565607 fbshipit-source-id: 94dd74a462526778f7a7e232a97b21211f95239f		2020-07-24 10:45:40 -07:00
..
src	revisionstore: add a new StoreResult type	2020-07-24 10:45:40 -07:00
Cargo.toml	debug: introduce error classification and metadata propagation	2020-07-15 10:03:10 -07:00