Per irc checkin, we expect changes on this before review.

I think I'm coming around on this. I've poked a few reviewers in private to look at the first three patches in this series to see how they feel, but if I don't hear back in a day or two I think I'll just push the whole stack...

In D8190#124146, @marmoute wrote:

In D8190#124141, @martinvonz wrote:

This new patch works, but I don't like the idea of not testing two fully independant process. Running a process through hooks is quite different and who know how that semantic could evolve.

In D8190#124141, @martinvonz wrote:

@durin42, what do you think?

I'd like to get back to pytyping all the things, but I can't justify spending more time on it. If someone else wants to push things forward I'll gladly provide some mentorship.

In D8281#124058, @marmoute wrote:

Since narrow is still experimental, I don't think we should try too hard for backward compatibility. We could introduce a new end-point for a new encoding and drop the old one in a couple of version.

In D8189#124124, @marmoute wrote:

In D8189#124122, @durin42 wrote:

I'm still -0 on this: I'd rather we found an approach that didn't require sleeping for so long. Perhaps a Python script would be a better fit here?
(I won't block this landing, but I won't push it.)

What abotu replacing the sleep 1 by a `python -c "import time; time.sleep(0.1)" would that make you happy ?

I'm still -0 on this: I'd rather we found an approach that didn't require sleeping for so long. Perhaps a Python script would be a better fit here?

In D8288#123836, @marmoute wrote:

For the record, I always use hg fix with --rev.

LGTM but needs rebased?

@marmoute

In D8189#123280, @marmoute wrote:

By using explicit wait on signal (through the fs) that each process reached the appropriate file. We avoid flackyness. There are already multiple use of this approach in the test suite, that does not suffer from flackyness (unlike the wheelbarrow of flaky test relying on sleep for sync).

In D8187#123306, @marmoute wrote:

In D8187#123258, @durin42 wrote:

No longer applies on top of @.

I don't understand this feedback. There are about 15 other changesets before it in this stack, so this is not meant to be directly applied on the head of default.

This script feels extremely like a flaky test waiting to happen. Is there no alternative for this?

No longer applies on top of @.