Summary:
Removed references to HgNodeHash in repo_client in the specified functions. In
addition, updated other files due to type related dependencies.
Reviewed By: StanislavGlebik
Differential Revision: D14543934
fbshipit-source-id: b0d860fe7085ed4b91a62ab1e27fb2907a642a1d
Summary:
Currently we read all bookmarks from primary replica a few times during `hg
pull`. First time when we do listkeys, second time when we get heads.
That might create a high load on primary replica.
However the delay between primary and secondary replicas is fairly small, and so it
*should* be fine to read bookmarks from secondary local replica as long as there is only
one replica per region (because if we have a few replicas per region, then
heads and listkeys response might be inconsistent).
Reviewed By: lukaspiatkowski
Differential Revision: D13039779
fbshipit-source-id: e1b8050f63a3a05dc6cf837e17a448c3b346b723
Summary:
Recently blobrepo_utils_tests started to deadlock. And it looks like it happens
because of `Future::wait()` in blobrepo_utils_tests macro - https://fburl.com/2jho0i2e.
I've added some logging in Mononoke and tokio code and got the following
sequence of events:
1) A test calls `Future::wait()`. Note that this blocks one of the worker threads
from the threadpool.
2) In `VisitOne::visit()` function (https://fburl.com/wmxvt7mq) the work is
split between the threads with `tokio::spawn()` function.
3) `tokio::spawn()` adds a future to some worker thread's queue.
4) If this worker thread is the thread that called `Future::wait()` then we get
a deadlock - recently spawned future can't complete because a thread is
blocked, and thread is blocked because `Future::wait()` waits for the spawned
future to complete.
This diff fixes by avoiding using `Future::wait()` and using tokio::spawn
instead.
Reviewed By: farnz
Differential Revision: D13021358
fbshipit-source-id: 6f1adda43f9460dc952e5794c2fa147b234731ee
Summary:
Alas, the diff is huge. One thing is changing Changesets to use ChangesetId.
This is actually quite straightforward. But in order to do this we need to
adapt our test fixtures to also use bonsai changesets. Modifying existing test
fixtures to work with bonsai changesets is very tricky. Besides, existing test
fixtures is a big pile of tech debt anyway, so I used this chance to get rid of
them.
Now test fixtures use `generate_new_fixtures` binary to generate an actual Rust
code that creates a BlobRepo. This Rust code creates a bonsai changeset, that
is converted to hg changeset later.
In many cases it results in the same hg hashes as in old test fixtures.
However, there are a couple of cases where the hashes are different:
1) In the case of merge we are generating different hashes because of different
changed file list (lukaspiatkowski, aslpavel, is it expected?). this is the case for test
fixtures like merge_even, merge_uneven and so on.
2) Old test fixtures used flat manifest hashes while new test fixtures are tree
manifest only.
Reviewed By: jsgf
Differential Revision: D9132296
fbshipit-source-id: 5c4effd8d56dfc0bca13c924683c19665e7bed31
Summary: This verifier works on manifests -- we'll need other ones for filenodes etc.
Reviewed By: StanislavGlebik
Differential Revision: D9105976
fbshipit-source-id: 939b72b6a3f69b716385315f69a57e91d71a45f3
Summary: This is a workaround for buggy commits produced by older versions of treemanifest.
Reviewed By: farnz
Differential Revision: D9018502
fbshipit-source-id: 71f2aeeaee01500a1a73814dc9c4979ef2c79746
Summary:
The goal of this tool is to verify that bonsai changesets roundtrip with the same hashes. This uses the `ChangesetVisitor` stuff introduced in the previous diff to walk over a specific number of changesets.
I've been using this tool for a few days, and it's shaken out a number of bugs in the Bonsai support in Mononoke, and even found old bugs in Mercurial. So it's been a pretty useful exercise overall.
Reviewed By: farnz
Differential Revision: D8817725
fbshipit-source-id: b6976e8ff9024098c695e82383d98d95b2701e1b
