- User Since
- Jul 1 2017, 5:02 PM (106 w, 5 d)
Sun, Jun 30
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.
Apr 5 2019
Apr 4 2019
Apr 2 2019
I would prefer you fix them :)
Was a newer version of this patch with the requested changes going to be uploaded? It's weird to see additional patches in the series without this one updated...
Mar 27 2019
Mar 25 2019
Mar 23 2019
I like the flexibility. But I'm not super keen about the interface here. Using a script to inject custom options seems like it could be useful. But as it is currently implemented, the script simply prints out \0 delimited package names. So one UI wart is --extra-prebuild-script being a somewhat generic name but that script only emits package names. --extra-packages-script would be a better name.
Mar 17 2019
Mar 16 2019
According to a private email, things were inconsistent because py2exe didn't (doesn't?) support bundling DLLs in the zip several years ago, so things *had* to be a certain way.