@pulkit You still wanted to explain what you mean with --in-reply-to interaction here.

Obsoleted by range based representation, which often works even better and doesn't depend on C.

Obsoleted by storing the phase changes as range, which is normally even more compact.

I haven't measured run-time impact. The sorting should ensure that the lists are normally kept small, but when many updates apply to very fragmented repositories, it could be worse. 20MB is relative to the 600MB peak RSS from the referenced issue.

Now blank and Python 3 clean.

The goal here is to allow something like "hg fast-export | git fast-import" to show a proper progress bar.
At the moment every write via ui.write and friends will hide the progress bar and re-enable it, even when stdout doesn't affect the terminal state. This would also make sense for operations like "hg diff", e.g. when writing a large/complicated diff to a file.

Will be implemented properly.

For the NetBSD repository, a trivial test with the new cache:

Friendly ping

Adjusted for most of the review comments. Added a test that books are left alone, since they will not be active in the interesting cases. I'm not touching any existing phases, so I'm not sure if I should do anything about phase testing?

It's used in reportphasechanges and that accidently turned O(n) into O(n^2). I noticed it when trying a clone --narrow of the NetBSD repo, since it hung for quite a while in that loop.