mirror of
https://github.com/facebook/sapling.git
synced 2024-10-10 16:57:49 +03:00
A Scalable, User-Friendly Source Control System.
895aa3c27a
Summary: This updates Mononoke to support LFS metadata when serving data over getpackv2. However, in doing so, I've also refactored the various ways in which we currently access file data to serve it to clients or to process client uploads (when we need to compute deltas). The motivation to do that is that we've had several issues recently where some protocols knew about some functionality, and others didn't. Notably, redaction and LFS were supported in getfiles, but neither of them were supported in getpack or eden_get_data. This patch refactors all those callsites away from blobrepo and instead through repo_client/remotefilelog, which provides an internal common method to fetch a filenode and return its metadata and bytes (prepare_blob), and separate protocol specific implementations for getpackv1 (includes metadata + file content -- this is basically the existing fetch_raw_filenode_bytes function), getpackv2 (includes metadata + file contents + getpackv2 metadata), getfiles (includes just file content, and ties file history into its response) and eden_get_data (which uses getpackv1). Here are a few notable changes here that are worth noting as you review this: - The getfiles method used to get its filenode from get_maybe_draft_filenode, but all it needed was the copy info. However, the updated method gets its filenode from the envelope (which also has this data). This should be equivalent. - I haven't been able to remove fetch_raw_filenode_bytes yet because there's a callsite that still uses it and it's not entirely clear to me whether this is used and why. I'll look into it, but for now I left it unchanged. - I've used the Mercurial implementation of getpack metadata here. This feels like the better approach so we can reuse some of the code, but historically I don't think we've depended on many Mercurial crates. Let me know if there's a reason not to do that. Finally, there are a couple things to be aware of as you review: - I removed some more `Arc<BlobRepo>` in places where it made it more difficult to call the new remotefilelog methods. - I updated the implementation to get copy metadata out of a file envelope to not require copying the metadata into a mercurial::file::File only to immediately discard it. - I cleaned up an LFS integration test a little bit. There are few functional changes there, but it makes tests a little easier to work with. Reviewed By: farnz Differential Revision: D16784413 fbshipit-source-id: 5c045d001472fb338a009044ede1e22ccd34dc55 |
||
|---|---|---|
| apiserver | ||
| async-compression | ||
| asyncmemo | ||
| benchmark | ||
| blobimport_lib/src | ||
| blobrepo | ||
| blobrepo_utils | ||
| blobstore | ||
| blobstore_sync_queue | ||
| bonsai_hg_mapping | ||
| bonsai_utils | ||
| bookmarks | ||
| bundle2_resolver | ||
| bytes-ext | ||
| cache_warmup/src | ||
| changesets | ||
| cmdlib/src | ||
| cmds | ||
| common | ||
| derived_data/src | ||
| failure_ext | ||
| filenodes | ||
| filestore/src | ||
| futures-ext | ||
| hgcli | ||
| hgproto | ||
| hook_tailer | ||
| hooks | ||
| manifest | ||
| mercurial | ||
| metaconfig | ||
| mononoke_api/src | ||
| mononoke_types | ||
| netstring | ||
| phases | ||
| py_tar_utils | ||
| reachabilityindex | ||
| ready_state/src | ||
| repo_client | ||
| revset | ||
| server | ||
| sshrelay | ||
| tests | ||
| .gitignore | ||
| .rlsconfig | ||
| .travis.yml | ||
| Cargo.toml | ||
| CONTRIBUTING.md | ||
| LICENSE | ||
| packman.yml | ||
| README.md | ||
| rustfmt.toml | ||
Mononoke
Mononoke is a next-generation server for the Mercurial source control system, meant to scale up to accepting thousands of commits every hour across millions of files. It is primarily written in the Rust programming language.
Caveat Emptor
Mononoke is still in early stages of development. We are making it available now because we plan to start making references to it from our other open source projects such as Eden.
The version that we provide on GitHub does not build yet.
This is because the code is exported verbatim from an internal repository at Facebook, and not all of the scaffolding from our internal repository can be easily extracted. The key areas where we need to shore things up are:
- Full support for a standard
cargo build. - Open source replacements for Facebook-internal services (blob store, logging etc).
The current goal is to get Mononoke working on Linux. Other Unix-like OSes may be supported in the future