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