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
..
basic.rs	mutationstore: deal with history being extended backwards	2020-06-25 06:29:15 -07:00
cycles.rs	mutationstore: deal with cycles when determining primordial changesets	2020-06-25 06:29:15 -07:00
main.rs	mutationstore: deal with cycles when determining primordial changesets	2020-06-25 06:29:15 -07:00
util.rs	mutationstore: deal with cycles when determining primordial changesets	2020-06-25 06:29:15 -07:00