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
