On Wed, May 5, 2010 at 05:31, Julian Foad <julian.f...@wandisco.com> wrote: >... > All the above: r941212.
Cool. >... >> > +/* Remove the pristine text with SHA-1 checksum SHA1_CHECKSUM from the >> > + * pristine store, iff it is not referenced by any of the (other) WC DB >> > + * tables. */ >> >> Also remember that we don't want to remove pristines why >> administrative locks (WCLOCK) are present. That may signify a commit >> is occurring and needed pristines are transiently living in the >> pristine storage. > > I need to think on this some more and learn about WCLOCK. > > If I'm using "pristine_remove" in a general garbage-collection manner > (outside of any code path that installs pristine texts), I would want to > bail if there are any entries in the WCLOCK table. Yes. I think. :-P ... if those locks are held by "this process", then sure... something may be holding the SHA-1 keys and will be doing something with those pristines. If the locks are *not* held by this process, then something else is doing some work (definitely skip GC'ing!) or a prior run failed in some way and there are stale locks remaining, pending an 'svn cleanup'. Presumably, there will also be some work in the queue. > If I'm using "pristine_remove" within a commit or update code path > (where I am also installing new text bases, but I can ensure that the > one I'm trying to remove is not one that I'm in the process of > installing), then I would want to bail if there are any locks in the > WCLOCK table *other than* those locks that are in WC_CTX. If the pristine is not in the table, and there are no Other Locks, then yes. I think this sounds right. I believe the design should be "pristines that need to live beyond locks require a reference from a table". Thus, if your process does not have a private reference to a pristine (known via code path), and no *other* process has one (by virtue of no WCLOCK), then you're free to GC pristines. Cheers, -g
