Julian Foad <julianf...@apache.org> writes: > Hello everyone. Thanks to sponsorship arranged by Karl, I'm able to work > on completing this.
Hi Julian, It's great to have you on board! > Important Question: > > * Is the approach with a WC format bump the best approach? > > I see two options to consider: > > * with format bump like this, plus completing the multi-WC-format > branch work > * re-work the implementation of the concept, to not change the > declared format number or DB schema, but instead to query "is the file > present on disk" instead of the DB 'hydrated' flag > > For each of those options, > > * what is the outcome in terms of interoperability? > * how much work is involved? (or is the 2nd one impossible?) Between these two options, I don't think that it would be actually possible to have the pristines-on-demand functionality available without a format bump, as the existing clients working with the current format rely on the pristine contents always being available on disk. Personally, I tend to think that making a format bump and accompanying it with the multi-wc-format support should work pretty well from a user's standpoint. > Right now I'm reviewing this work and the long discussion about it and > I will come back with a summary and plan for your consideration, and no > doubt many questions, in the next few days. Perhaps, one way to start off would be to fix the temporary assumption that any working copy of the newer format always fetches the pristines on-demand. While the final way of configuring that undoubtedly is an important question to answer, there might be a way to make progress while keeping the configuration simple, at least for now: — Make the "are pristines being fetched on-demand" a property of the working copy — Introduce a new configuration option that controls this new behavior and is applied at the moment when a working copy is created I think that carrying these steps would bring the feature closer to its final shape, and would also mean that a lot of the important subsurface work (such as preserving the old behavior for existing working copies, running the tests for both configurations, etc.) is already in place, so that we wouldn't have to think about it further on. Thanks, Evgeny Kotkov
