I still need to look at this commit in detail, but any commit that alters the on-disk or on-network behavior of Mercurial should ideally be accompanied by a docs change to mercurial/help/internals. I say ideally because some things still aren't documented. But repo requirements are. Please follow up with a patch to document the new requirement in mercurial/help/internals/requirements.txt.
Fri, May 17
Wed, May 15
Sat, Apr 27
Wed, Apr 24
Ideally the new part would be documented in internals.bundle2. But other narrow parts aren't documented, so maybe we can hold off...
Apr 22 2019
Apr 21 2019
Apr 20 2019
Apr 19 2019
Apr 17 2019
+1 for feature. Needs some minor work to get review.
Do you have performance numbers to share? Substantial wins would definitely pique my interest :)
An idea to consider (which may have been proposed already) is to write a *no copy metadata* entry into extras when writing copy metadata to the changelog. If we did things this way, a new client could know definitively that no copy metadata is available and to not fall back to reading from the filelogs. I haven't fully thought this through, but that should provide better compatibility between older and newer clients. Obviously the tradeoff is you could have a mixed repo (some changesets wouldn't have copy metadata in changelog) and you would need to duplicate copy metadata across changelog and filelogs to maintain compatibility. Something to contemplate...
I support experimenting with putting copy metadata in the changelog. And the patches before this one did a lot of work to allow copy metadata to be read from alternate sources, which is great, since it can allow flexibility in the future (think copy caches, copy modifications outside of a commit, etc).
This patch is backwards incompatible over the wire protocol.