Julian Foad <julian.f...@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
