Summary:
If the first client to send mutation data for a commit is only aware of partial
history for that commit, the primordial commit that is determined will be the
earliest of those commits. If another client comes along later with a longer
history, the new set of commits will be assigned a different primordial commit.
Make sure that when this happens, we still fetch the full history. We do this
by including the successor in the search-by-primordial case, which allows us
to join together disconnected histories at the cost of one extra round-trip to
the database.
Note that the fast path for addition of a single mutation will not fill in the
missing history. This is an acceptable trade-off for the faster performance
in the usual case.
Reviewed By: mitrandir77
Differential Revision: D22206317
fbshipit-source-id: 49141d38844d6cddc543b6388f0c31dbc70dcbc5
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
9a6ed4b6ca