On 13.01.2011 20:01, Julian Foad wrote: > I have committed the ref counting for pristine texts (r1058523) and have > had a bit more insight into when to perform the deletion. > > Deleting unreferenced texts on closing a "wcroot" is too late - too > large a granularity - for the way the WC code is currently structured > because this doesn't happen until a (long-lived) pool is cleaned up, as > Bert pointed out. > > Deleting unreferenced texts after running the Work Queue is too soon - > too fine a granularity - for the way "commit" is currently structured. > A simple test of this approach showed that by the time the post-commit > processing tries to install a reference to a pristine text whose > checksum was noted earlier, in some cases that pristine row has already > been purged.
This would indicate that the reference counting happens too soon ... in other words, that a pristine can be dereferenced whilst some part of the code (or database) still refers to it. That breaks database consistency -- what happens if the user aborts a commit and then calls 'svn cleanup', for example? > At the moment I think the practical solution is to insert calls to the > pristine cleanup at the end of each main libsvn_wc public API that may > have freed up one or more pristines. Mmm. Too many points of failure, don't you think? Of course, it's no "worse" than the cancellation handlers, however, and I suppose missing a chance to delete is better than having one too many. > Wherever we do it, if it's at all frequent, the search for unreferenced > pristines needs to be efficient. At present I use "SELECT ... FROM > PRISTINE WHERE refcount = 0". I believe that can most easily be made > efficient by adding an index on the 'refcount' column, so that's what I > intend to do. That's the only thing you can do, unless you want to enhance the triggers to populate a queue of to-be-deleted pristines. -- Brane
