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