> multi-wc-format branch [...] anything I'm missing? As soon as I stepped away I could see 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.
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. 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. - Julian
