Summary:
The bulk api makes less queries to mysql and therefore is more efficient.
This is especially important for `hg pull` requests where the list of heads is very large.
Reviewed By: lukaspiatkowski
Differential Revision: D13677298
fbshipit-source-id: 3dec1b3462c520c11481325e82523ef7a6ae6516
Summary:
the remaining part to implement bulk phases fetch and update
this is required to optimize number of MySql queries we are using to look up at the db for phases and bookmarks.
the single get api has been removed and reimplemented by calling bulk ones
Reviewed By: aslpavel
Differential Revision: D13664900
fbshipit-source-id: 29342e86c057b92e331fadcebe51f452d9569e09
Summary:
this is required to optimize number of MySql queries we are using to look up at the db for phases and bookmarks.
the next step is to add the same with Memcache to caching.rs
implementations for the single get is replaced with just calling the implementation for multiple get
Reviewed By: aslpavel
Differential Revision: D13658610
fbshipit-source-id: e3876044e2cbbefb156175c51ab7051db3885eb8
Summary:
use the correct skip index
sorry for some rustfmt.
Reviewed By: StanislavGlebik
Differential Revision: D13636059
fbshipit-source-id: 2815d82b63b86bda053f5a3a9a1b8a3b72abbf82
Summary:
We have decided that this will be used to transport phases to the client
Hg client already supports this part.
Reviewed By: StanislavGlebik
Differential Revision: D13507921
fbshipit-source-id: 621e93bb6e1a0c87d4f4963ba7fa635b77a5b6ec
Summary:
Basically if any of the bookmarks is reachable, all other bookmarks are not
interesting to check, so those futures should be skipped.
Reviewed By: StanislavGlebik
Differential Revision: D13538511
fbshipit-source-id: 193a7ea8d505690aeb96247a07c8f2688cd7a59f
Summary: There's nothing Mercurial-specific about identifying a repo. This also outright removes some dependencies on mercurial-types.
Reviewed By: StanislavGlebik
Differential Revision: D13512616
fbshipit-source-id: 4496a93a8d4e56cd6ca319dfd8effc71e694ff3e
Summary:
New HintPhases api that will be used for tests vs CachingHintPhases that will be used in prod.
The api will be owned by RepoClient.
We will check what type of BlobRepo we have (i.e. blob:rocks, blob:files, blob:remote etc) and build the phases depending on the type of the BlobRepo.
We will use either CachingHintPhases backed by real db / MyRouter or HintPhases backed by Sqlite.
Reviewed By: StanislavGlebik
Differential Revision: D13466225
fbshipit-source-id: 06ea565171d8ea8d7335fbbd91d86fbdcc01c8fc
Summary: Calculation is based on beeing ancestor of a public bookmark
Reviewed By: StanislavGlebik
Differential Revision: D13441622
fbshipit-source-id: e20df656847913bc124b491aaeb2660d21c85da1
Summary:
This diff includes the logic on how we will receive a phase for a given commit based on memcahe / db lookup and refresh, and slow path calculation.
It has a blank place of slow path (not found in the memcache, not found in the db => we have to calculate the phase based on being ancestor of public bookmark).
Collecting the stats should be added separately.
Reviewed By: StanislavGlebik
Differential Revision: D13415481
fbshipit-source-id: 6a4cb5b8dfbb0d7b2535d903c653bbf7a088c422
Summary: add/get api for adding phases to mysql phases table
Reviewed By: lukaspiatkowski
Differential Revision: D13376701
fbshipit-source-id: b71e52db2c30b59b0070f49327bfdd189c28d6cc
