OK everyone, here are lots of observations and questions to start off.
I have built and "kicked the tyres of" the current 'pristines-on-demand'
branch, and have skimmed through its changes.
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
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,
* corresponding format bump and upgrade code,
* corresponding modifications to WC-layer pristines handling,
* 'textbase_sync' calls added before and after relevant client-layer
operations, to hydrate and dehydrate any relevant files, seems to be the
main substance of the high level logic.
I would very much appreciate anyone able to review the WC code changes
to any extent. I feel the depth of review I can offer is limited in
this area.
Important Question:
* Is the approach with a WC format bump the best approach?
I see two options to consider:
* with format bump like this, plus completing the multi-WC-format
branch work
* re-work the implementation of the concept, to not change the
declared format number or DB schema, but instead to query "is the file
present on disk" instead of the DB 'hydrated' flag
For each of those options,
* what is the outcome in terms of interoperability?
* how much work is involved? (or is the 2nd one impossible?)
How would these compare as overall solutions from a user perspective?
Some notes:
* Reworking Evgeny's code would obviously require considerable effort.
* Using a new field in the database of course is the best way to
store that data measured by cost per lookup. However that by itself
doesn't guarantee the best overall end result.
* Getting the multi-WC-format work done now also buys us future
WC-format compatibility scenarios as a bonus.
* If the multi-WC-format branch is incorporated, I'm not yet clear
what interop story that gives us. I'll try to learn that next.
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
The user experience of the current 'pristines-on-demand' branch seems
pretty good for basic scenarios. Questions I haven't asnwered yet:
* Does it fetch more pristines from the server than are needed by
the operation in progress, in some cases?
While I'm working on answering all these questions, I would very much
appreciate any advice and insight anyone can offer.
- Julian
