Branko Čibej wrote on Sun, Jan 16, 2022 at 21:37:15 +0100: > On 14.01.2022 21:29, Julian Foad wrote: > > 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. > > My original motivation to starting multi-wc-format was to implement > compressed pristines and in-wc-db pristines for small (for some definition > of) files. There may be a branch for that (I don't recall)
There are two: * compressed-pristines (https://svn.apache.org/repos/asf/subversion/branches/compressed-pristines/BRANCH-README?p=r1897404) * better-pristines (https://svn.apache.org/repos/asf/subversion/branches/better-pristines/BRANCH-README?p=r1897404) Incidentally (and off-topic for this particular subthread), there's also a pristineless-hack branch: https://svn.apache.org/r1769826 > and some infrastructure work in spillbufs that could be reused. > > > 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. > > That would be my recommendation, too, if only to have just one specific way > to add feature support to the WC without requiring a WC upgrade every time. > We've mostly tied WC features to the format version, it would seem natural > to keep that correlation.
