[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: WCNG: Deleting unreferenced pristine texts

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Fri, 10 Dec 2010 15:13:02 +0000

Julian Foad <julian.foad_at_wandisco.com> writes:

> Until recently I have been thinking the best way is to code the "remove
> this one" call into the appropriate place in each libsvn_wc code path,
> but I'm changing my mind. That's feasible in some places but I think
> it's too difficult in general, because some of the places where we lose
> a reference are down within some WC-DB-layer function that may delete or
> overwrite several rows as part of its operation.
>
> Instead, I think we should be using some kind of reference-counting or
> reference-tracking in the WC-DB layer. It could use the 'refcount'
> column that already exists in the 'pristine' table. It could use a
> separate list of "pristines that may have become unreferenced" which
> could accumulate in the DB during the course of a high-level operation
> and could then be scanned at the end of the op, perhaps after processing
> the Work Queue.

If a code path makes it difficult to remove individual pristines how
will it be possible to update the reference count?

I wonder if an SQLite trigger could be used.

> I'll also look into the possibility of working to a constraint that
> every pristine SHA1 reference in the DB should at all times refer to an
> actual entry in the 'pristine' table. At the moment, as I understand
> it, we may sometimes insert the reference before installing the
> referenced text. That's not necessarily wrong but I feel we'd have a
> stringer design if we can re-order the code such that this constraint is
> satisfied at all times. I see from the SQLite docs that a 'REFERENCES'
> constraint can be enforced by sqlite >= 3.6.19.

We alrady use REFERENCES for wc_id and repos_id.

-- 
Philip
Received on 2010-12-10 16:13:47 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.