Where do we stand on the intent to mass reformat the code base?

I think this patch can be abandoned because of other work late in the 4.8 cycle?

Ideally we'd be using the vfs layer for I/O. But that is scope bloat and I'm not going to make you rewrite RFL to do things more correctly.

IIRC we #define PyInt and PyLong in the source for Python 3 compatibility. I remember doing something really hacky to unblock getting the C extensions to compile on Python 3 at the Paris sprint. It would definitely be a good idea to audit everything with PyInt and PyLong in it for sanity.

In D4750#73744, @mharbison72 wrote:

Apparently thg uses this to avoid loading the data into memory just to figure out the length like fctx.rawsize(). Any suggestions?

https://groups.google.com/d/msg/thg-dev/6ekYID7ho_o/fbdd6rVDAwAJ

db5501d93bcf6ada3426a45e901094fd877e370f changed a test. I'm surprised this patch doesn't include that revert as well. I'll verify the test as part of landing and amend as necessary.

Yeah, I'm OK with this. There is tons of room to experiment with different ordering techniques - including making it end-user configurable. Having this code in place is a step in the right direction.

In D5194#77606, @martinvonz wrote:

Is this useful enough to others that it should live in the hg core repo? It doesn't seem like it to me, but maybe I'm wrong.

There are no children reviews of this one. Could you please set the parent-child relationships so the entire stack renders in the web UI?

I'll hold off formally accepting until the whole series is up. But this looks pretty good.

! In D5130#76736, @mharbison72 wrote:
Will do. How hard do you think it will be to do the same thing for pull?

I'll resubmit this as part of another series.

Per discussions at 4.8 sprint, we're going to hold off on this.

Per discussions at 4.8 sprint, we're going to hold off on this.

Thank you for finishing what I started and implementing this properly (by adding a separate server-side capability to distinguish between LFS states).

I need to give the final state of the code a final one-over. I will do that after breakfast.

The optics to removing this are a bit bad because efficient pack transfer can lead to significant performance gains. While I think the use of packs in Mercurial for exchange will occur at some time, the path to stabilization in core is not clear and will almost certainly see a BC break from this code. I'm fine removing this functionality from RFL for now. We can always add something similar later.

Yuck. But the names don't matter much for an experimental feature. And the wireproto v1 peer batching code dictates certain things with regards to naming. So our hands are a bit tied here :/

\o/

Nice catch on the overloaded capability name! Constants are better for expressing intent.