Tue, Aug 6
Sun, Aug 4
Sat, Aug 3
The presence of __del__ is a bit dangerous and I've debugged a handful of issues related to having __del__ on transaction. We still leak repo objects in places due to circular references. It's super annoying.
Mon, Jul 29
Wed, Jul 24
Mon, Jul 22
This series is for stable. (I forgot Phabricator didn't handle branch names well.)
Jun 30 2019
May 28 2019
I'm also not super crazy about abusing extras for this. But it is the best compromise considering the "better" solutions require a lot more effort and thought. At some point, I would like Mercurial's storage and wire protocol to grow official APIs for storing and exchanging arbitrary data outside the current storage primitives. Maybe we can shoehorn storage into revlogs in .hg/store/meta. I dunno. Feels like sprint material to me.
May 24 2019
May 17 2019
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.
May 15 2019
Apr 27 2019
Apr 24 2019
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.