On Thu, 2011-01-13, Branko Čibej wrote: > 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
Just want to say thanks for your feedback, Brane. Due to other work commitments I may not have much time to take this forward over the next three weeks. - Julian
