I want to ensure libsvn_wc deletes the pristine texts that it is no
longer referencing. At the moment, some code paths call
svn_wc__db_pristine_remove() when they stop referencing an old one, and
other code paths don't, so we leak and the pristine store grows.
"svn cleanup" finds and removes all the unreferenced ones.
My position on 1.7 readiness is that we ought to be keeping the store
clean, automatically, most of the time, although it doesn't matter if we
ship with a buggy case or two in which they leak because the manual
cleanup is a usable work-around.
Until recently I have been thinking the best way is to code the "remove
this one" call into the appropriate place in each libsvn_wc code path,
but I'm changing my mind. That's feasible in some places but I think
it's too difficult in general, because some of the places where we lose
a reference are down within some WC-DB-layer function that may delete or
overwrite several rows as part of its operation.
Instead, I think we should be using some kind of reference-counting or
reference-tracking in the WC-DB layer. It could use the 'refcount'
column that already exists in the 'pristine' table. It could use a
separate list of "pristines that may have become unreferenced" which
could accumulate in the DB during the course of a high-level operation
and could then be scanned at the end of the op, perhaps after processing
the Work Queue.
I'll also look into the possibility of working to a constraint that
every pristine SHA1 reference in the DB should at all times refer to an
actual entry in the 'pristine' table. At the moment, as I understand
it, we may sometimes insert the reference before installing the
referenced text. That's not necessarily wrong but I feel we'd have a
stringer design if we can re-order the code such that this constraint is
satisfied at all times. I see from the SQLite docs that a 'REFERENCES'
constraint can be enforced by sqlite >= 3.6.19.
Any immediate thoughts?
- Julian
Received on 2010-12-10 15:47:03 CET