sapling/eden/mononoke/mercurial
Mark Thomas 9a6ed4b6ca mutationstore: deal with history being extended backwards
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
2020-06-25 06:29:15 -07:00
..
bundles remove HgPhase type 2020-06-22 13:51:33 -07:00
mutation mutationstore: deal with history being extended backwards 2020-06-25 06:29:15 -07:00
revlog fix unused dependencies breakages 2020-06-19 06:49:04 -07:00
types remove HgPhase type 2020-06-22 13:51:33 -07:00