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
Received on 2011-01-13 20:57:55 CET