On 14 Jan 2022, Julian Foad wrote:
I looked into the multi-wc-format branch today. Brane wrote
previously:
This basically needs the following:
* a huge sync with trunk;
Done.
Nice :-). (Understatement is the height of style, ahem.)
Now I'm considering what would be the pros and cons of using
'multi-wc-format', compared with if it's possible to modify the
pristines-on-demand implementation to work with no format bump
but just
an on-disk variation of the current WC format. (We haven't proved
it's
possible nor that it's impossible.)
It's worth some exploration. If we absolutely have to have a WC
format bump, it's not the end of the world, but it'd be great if
we can avoid it.
As soon as I stepped away I could see [the differences] more
clearly:
Basically 'multi-wc-format' is just providing an API up to the
client layer for enumerating WC format variants. The same logical
functionality could be implemented for a particular feature
(e.g. pristines-on-demand) by looking directly at some other
on-disk representation change to distinguish variants within one
format number; this branch just formalizes and generalizes it. It
doesn't make more or better compatibility than could be done
ad-hoc; it doesn't magically make old clients be able to work
with newer formats/variants than they know about.
Nice summary. This makes complete sense and is what I sort of
suspected the 'multi-wc-formats' branch was doing, in fact.
So, in the context of whether it makes sense to adopt the
'multi-wc-format' branch versus implementing the WC pristines
code to
work ad-hoc with two on-disk variants, it comes down to:
- cost of adopting (reviewing etc.) the 'multi-wc-format' vs.
implementing something ad-hoc for pristines;
- potential future benefit from re-using 'multi-wc-format' for
other changes.
Cost of adopting 'multi-wc-format' looks likely to be lower. It
is
mostly boiler-plate changes and simple code, and is fairly small
compared with the overall task:
'pristines-on-demand' diff size: +2700 -1000 lines roughly
'multi-wc-format' diff size: +1000 -200 lines roughly
From this perspective, it looks best to adopt 'multi-wc-format'
unless
we find some show-stopper problem with it.
Agreed.
p.s. I forgot to say, in updating 'multi-wc-format' I found a few
small
problems, two of which I fixed; one remains, causing the
'upgrade' tests
to fail, which is due to '#ifdef SVN_TEST_MULTI_WC_FORMAT' in
'wc-metadata.sql', which doesn't get processed as a directive and
needs
to be handled some other way.
Ah, doesn't seem like a showstopper, certainly :-).
Best regards,
-Karl
