Karl Fogel wrote: >> * pristines are missing until needed (for diff, commit, >> [...] > > Hmmm, why would pristines be needed for commit?
Oh you're right, I forgot, we've already been through this: originally it fetched them, people discussed, then Evgeny posted a tweak to make it send full texts instead. >> FWIW, the interop behaviour of current 'pristines-on-demand' >> branch by itself is: >> >> * new svn errors on an old WC; recommends 'svn upgrade' >> * new svn 'svn upgrade' quickly upgrades the WC in place, >> removing >> pristines of all unmodified files >> * old svn errors on a new WC > > No reason to upgrade an old WC until someone actually wants an > optional pristine. In principle, an what we ideally desire, agreed. Here I was just saying what this branch does as it is now, before being combined with the multi-wc-format work, which we're told is needed to accommodate what we desire. (I'll be looking into exactly what this means and whether avoiding WC database changes and using on-disk pristine presence alone is a feasible (perhaps even superior) alternative, as I mentioned.) > Also, the point of this feature is not to remove pristines for all > unmodified files. It's to make it possible for users to specific > certain circumstances (generally involving large file size!) in > which the pristine should be omitted *for certain files*. Understood. That ability (to pick and choose which files it applies to, by some client-side config) will need to be added. I'll be looking into it. > I expect an old svn to error on a new WC *when that new WC > actually has some already-omitted pristines*. Other than that > circumstance, there's no reason an old SVN shouldn't work -- it'll > just not implement the "optional pristines for certain files" > feature, and the working copy will be larger than it otherwise > might have been. If it's important to the user to upgrade their > svn to get some optional pristines, then the user can do so. Understood, and exploring to what extent that may be possible. - Julian
