de7fd72ed3
Summary: The goal of the stack is to support hot reloading of `CommitSyncConfig`s everywhere: in `push_redirector`, `backsyncer`, `x-repo sync job` and so forth. This diff in particular is a refactoring of how we instantiate the `PushRedirector` struct for the `unbundle` flow. Previously the struct would be instantiated when `RepoHandler` struct was built and would later be reused by `RepoClient`. Now we want to instantiate `PushRedirector` before we start processing the `unbundle` request, so that we can request the newest `CommitSyncConfig`. Note that this diff does not introduce the hot reload itself, it just lays the groundwork: instantiation of `PushRedirector` at request start. To achieve this goal, `RepoClient` now contains a somewhat modified `PushRedirectorArgs` struct, whose goal is to own the unchanging stuff, needed to create a full `PushRedirector`. Here are a few explicit non-goals for this hot reloading: - the overall decision whether the repo is part of any `CommitSyncConfig` or not is still made at `RepoHandler` creation time. What this means is that if `CommitSyncConfig` is changed to have another small repo and Mononoke servers happens to know about that repo, it would not automatically pick up the fact that the repo should be a part of `CommitSyncConfig` - same for removal (stopping push redirector is already possible via a different hot-reloaded config) - changing anything about a large/small relationship is likely to be very complicated under the best circumstances of everything being down, let alone during a hot reload. This means that target repo cannot be changed via this mechanizm. Essentially, the goal is only to be able to do a live change of how paths change between repos. Reviewed By: StanislavGlebik Differential Revision: D21904799 fbshipit-source-id: e40e6a9c39f4f03a436bd974f3cba26c690c5f27 |
||
---|---|---|
.. | ||
backsyncer | ||
benchmark | ||
blobimport_lib | ||
blobrepo | ||
blobrepo_utils | ||
blobstore | ||
blobstore_sync_queue | ||
bonsai_git_mapping | ||
bonsai_globalrev_mapping | ||
bonsai_hg_mapping | ||
bookmarks | ||
bulkops | ||
cache_warmup | ||
changesets | ||
cmdlib | ||
cmds | ||
commit_rewriting | ||
common | ||
config_structs | ||
derived_data | ||
edenapi_server | ||
fastreplay | ||
filenodes | ||
filestore | ||
git | ||
gotham_ext | ||
hgcli | ||
hgproto | ||
hook_tailer | ||
hooks | ||
lfs_import_lib | ||
lfs_protocol | ||
lfs_server | ||
load_limiter | ||
manifest | ||
megarepolib | ||
mercurial | ||
metaconfig | ||
microwave | ||
mononoke_api | ||
mononoke_types | ||
mutable_counters | ||
newfilenodes | ||
permission_checker | ||
phases | ||
pushrebase | ||
reachabilityindex | ||
repo_client | ||
repo_import | ||
revset | ||
scs_server/src | ||
segmented_changelog | ||
server | ||
sshrelay | ||
tests | ||
time_window_counter | ||
tunables | ||
unbundle_replay | ||
walker | ||
Cargo.toml | ||
README.md |
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.
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