On Wed, Jan 12, 2022 at 1:40 PM Karl Fogel <kfo...@red-bean.com> wrote: > > On 12 Jan 2022, Julian Foad wrote: > >It works as advertised in simple usage: > > > > * pristines are missing until needed (for diff, commit, > > revert, > >resolve, etc.), > > * corresponding disk space reduction > > * (and speed differences such as faster checkout, slower > > diff) > > * fetches pristines when needed, deletes them afterwards > > Hmmm, why would pristines be needed for commit? > > >It also passes the (branch) test suite, although I note on the > >branch > >there are modifications to some tests and some are skipped; I > >haven't > >yet reviewed what and why. > > > >In skimming through the branch diff I noted: > > > > * extra 'hydrated' flag column added in the WC DB 'pristine' > > table, > > Very nice choice of adjective -- kudos to Evgeny :-). > > >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. > > 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*. > > 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. > > > * Does it fetch more pristines from the server than are > > needed by > >the operation in progress, in some cases? > > Like maybe commit? :-) > > Best regards, > -Karl
I was about to click "send" and then Karl replied, so I'll update my reply accordingly... ok done :-) It sounds like the feature is planned to be opt-in (working copies are same as before unless the feature is activated), but do we want to consider opt-out (new working copies are smaller by default unless users request locally cached pristines) or some other option such as, e.g., "smart" (applies automatically to files over some size, method to set this threshold TBD)? Once a pristine is fetched, do we want to delete it automatically or wait until the user runs a cleanup operation? Also there is the question of how the option is activated: per-file, per-wc, per-user, per-system? I could envisage at least one example use case for each of these possibilities: * per-file: A repository contains one unusually large file that does not change often; the admin sets it to no-pristine to save everyone the headache * per-wc: A developer with a fast connection to the repository checks out a large codebase (hundreds of MiB of sources) onto a RAMDISK for faster compile/debug cycles with reduced wear on FLASH memories; network overhead for diffing, etc., is minimal * per-user / per-system: The user's repo and wc are on the same machine and there is never a need for pristines. Answer(s) to the above questions may have a pretty significant effect on the scope and design of the feature, both immediate and possible future directions, so I think it's important to think about this carefully. Cheers, Nathan
