mirror of
https://github.com/facebook/sapling.git
synced 2024-10-11 01:07:15 +03:00
472ec19699
Summary: Rolling out LFSv2 on fbsource is a bit complex. Initially, the intent was to roll it out via a server-only config and send pointers to say 5% of the clients. The big snag in this is that LFS pointers are stored in Memcache, and thus, a client who wasn't supposed to use LFS may end up reading a pointer from Memcache, and issuing a request to the LFS server. Thanks to the way Memcache works, this may lead to an avalance effect where everyone is fetching LFS blobs, even if the server rollout is at a small percentage. There are several solutions to this, the first obvious one would be to simply not use Memcache for pointers, but that also means a forced connection to the server, and a higher latency, ie: not a very desireable situation. An alternative would be to have a proper capability exchange at connection time, but that's unfortunately not feasible today due to the need to support the old Mercurial server. Long term this is definitively the approach we want to go to, and depending on the exchanged capabilities, we can even imagine using different memcache keys automatically. For now, we can hack this up by re-using the only free-form channel that the client has to the server: clienttelemetry. Mononoke can then use the passed in information to decide on whether to send LFS pointers (or not). This unfortunately means that the rollout will be entirely client-side driven. To alleviate the issue of Memcache keys being shared between clients wanting LFS pointers and the ones not wanting them, a different Memcache key space will be used. Reviewed By: StanislavGlebik Differential Revision: D21765065 fbshipit-source-id: aebda3c567a827342b2fa96d374a06a23ea0ca34 |
||
|---|---|---|
| .. | ||
| fs | ||
| integration | ||
| locale | ||
| mononoke | ||
| scm | ||
| scripts | ||
| test_support | ||
| test-data | ||
| win | ||
| .clang-format | ||
| .gitignore | ||
| Eden.project.toml | ||