As documented in , this is still tentative and could be subject to change,
but we need to lay down the foundations in order to work on the next abstraction
Can we get space for extra flags for things not supported by the filesystem? I'm thinking specifically +x and symlink support on Windows.
Couple of changes from this patch can be separated and send individually as prepare for revlog v2 which will help speed up review.
|3639 ↗||(On Diff #25185)|
This can be a separate patch and will be easy one to push.
IIUC, this change can also be a separate patch.
I'm not going to review this right now, but I have prior art at https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-February/093657.html and https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-May/097960.html that might be worth a read. I believe the wiki page on this format only contains a subset of the deficiencies I outlined in the 1st link.
Thanks for pasting these links. I'll look at them pretty soon, and we'll definitely have to account for whatever deficiencies I haven't covered in the plan page before we actually settle on a format.
This patch series is still valid for the short-term because it enables work around side-data and copytracing that would not be possible without a new format.
I don't think the meaning of these are documented anywhere, it would be nice to use the fact you know what they mean to document them.
should the constant be factored beetween the previous file and this one ?
like indexformatv2 = struct.Struct(pureparser.Index2Mixin.index_format) in this case, the documentation would move to the pureparser module.
Should this be in an independant changeset ? Should we bump it to something much hight than (3) to avoid the same problem in the next iteration ?