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
Received on 2011-01-17 14:15:17 CET