On 10 Feb 2022, Julian Foad wrote:
My current plan:
* multi-wc-format is, I consider, ready for merge to trunk. See
thread [1].
-> Please review it.
- I can post a diff and a summary log message to help
reviewers.
* Make pristines-on-demand behaviour conditional on WC format.
- The changes are mostly simple if a bit fiddly. In libsvn_wc
we
will need a bit of futzing around with two variants of some
existing
wc-db queries, one with and one without the extra 'hydrated'
column, to
work with both DB formats.
* Re-base pristines-on-demand on top of multi-wc-format.
- I have this ready in a working copy.
- The one significant change is to remove the new bits from
the main
DB schema statements, so that it will create format 31 not 32, as
the
new way (multi-wc-format) is to always create the baseline
(lowest
supported) format first (which will be 31) and then run the
statements
that upgrade it to any higher requested format (specifically,
when 32 is requested).
* Finish the per-WC configuration. See thread [2].
-> Please review the plan there.
At that point I would consider the feature a minimum viable
product
(MVP), ready to merge and ready for use.
Please do speak up with any comments.
Agree about MVP being ready by that point. My only question is
about a matter of intra-dev communications:
The name of the "pristines-on-demand" branch implies a certain
behavior -- namely, that pristines can, via some UI, be fetched on
demand :-). But in the MVP we're talking about, pristines in a
given WC are either all present or all absent, and, at least for
MVP, that per-WC state is not changeable, right? (That is, MVP
doesn't include dehydration or rehydration, IIUC.)
Again, just to be clear: I think that's fine and the MVP will be
very useful, even before any [rd]ehydration feature is available.
But does the "pristines-on-demand" branch name still accurately
reflect what the state of the onion will be after that branch is
merged?
Best regards,
-Karl
