In D7492#111595, @martinvonz wrote:

Hmm, I thought this entire series had been queued. I'd like to queue it. Can you include perf numbers?

For those who wants to see the test misbehaving, your just need to run it in a loop on heavy load:
python run-tests.py --runs-per-test 10000 --loop -j 90 test-remotefilelog-bgprefetch.t

good spot. I'll update that last patch.

target is the stable-branch

target is the stable-branch

target is the stable-branch

target is the stable-branch

target is the stable-branch

target is the stable-branch

target is the stable-branch

Any update on this ? I'll need it for my work on copy tracing. Reading the review thread, there is no remaining blocker to land this.

I am fine with not having all test passing from the start. However here we have a test that used to pass that is now failing, so we regressed here. I would rather not regress in test coverage here. Without this, all mercurial test pass with the Rust code, I would like to keep it that way.

In D7503#110631, @yuja wrote:

> Okay, then using non-debug `assert!()` seems more appropriate. If we prefer
> being stricter, "checked" HgPath type can be introduced.
> ...
> Actually I tried to suppress these warnings by propagating Result upwards,
> and I got a feeling that we're doing wrong.
I sent a followup as D7522 <https://phab.mercurial-scm.org/D7522> because that gets rid of the warnings. As explained in the commit message, I am unhappy about this change, as you seem to be.

Thanks. Given Rust impl is still unstable, I think it's better to back out
the changes in Rust and leave the test failure until we find a right solution.

In D7512#110590, @mharbison72 wrote:

@marmoute?

In D7481#110524, @yuja wrote:

+ if specs == [b'null']:
+ return revset.baseset([nullrev])

This breaks --config revsetalias.null=<whatever>. Nobody would care, but
I don't know why we're so hard to optimize -r null query.