On Nov 23, 2009, at 11:07 AM, Philip Martin wrote: > "Bert Huijben" <b...@qqmail.nl> writes: > > Thanks! Some of my questions may not have been very clear, there may > have been confusion between "Subversion locks" and "SQLite locks", but > your answers were good enough.
Yes; thanks, Bert. My explanations can be a bit muddled at times. >> An atomic transaction which checks the existance of a write lock inside a >> sqlite transaction can't be interrupted by another process taking the write >> lock.. As that would require breaking the sqlite transaction. > > The transaction ensures there is no other write lock, or it has its > own write lock or whatever, and the transaction only completes if it's > true. That sounds plausible. It's not how the current write lock > checking occurs is it? At present the code checks a boolean flag in > the PDH struct. We've gradually been moving code from the access baton into the wc_db, which internally uses the PDH struct, and from on-disk files to the sqlite database. An entry in the WC_LOCK table answers the question "has this directory been locked for writing?" and the LOCKED member of the PDH answers the question "does the write lock belong to this process?" This is the same paradigm that access batons have been using, and since we've moved it into the wc_db, it's translated pretty well using our per-directory sqlite databases. However, that scheme will shortly disappear, so things have been a bit, shakey while we feel our way around the new locking scheme implementation (especially since we don't yet have centralized metadata). >> I agree that we should be able to take some shortcuts in the transition >> period towards WC-NG, because keeping all guarantees up (around loggy as >> poor mans transaction, etc.) takes an insane amount of extra work that can >> be /dev/null-ed a few weeks later, when the working queue items and pristine >> handling replace most of the loggy stuff. > > Are the shortcuts listed anywhere? How close are we to centralised > metadata? I'm still not sure what I should do about code that tries > to open an sqlite database that no longer exists. Would it be > sensible to make that "not an error" on the basis that it is one of > the shortcuts? Centralized metadata is basically waiting on a few prerequisites: * Get rid of all calls to svn_wc__entry_modify2() * Move properties into the sqlite database * Implement proper pristine handling (a sha-1 indexed datastore) * Write the upgrade code to centralize the metadata The properties migration is all but complete. I've got properties-in-sqlite in a working copy locally, but the upgrade process is borked and needs to be fixed before we move the properties. It's been on my stack for the past couple of weeks, but has been repeatedly preempted. :( As was mentioned earlier, there's been some discussion, and a general understanding that some of the concurrency protections will be loosened on trunk while we do the transition. In the end, we expect to use sqlite transactions for much of our concurrency needs, but there will still be times when we need to have explicit write locks on the database. We may need to go and audit the code once we are finished, but I'm hoping the new (and much simpified) locking scheme makes that easier. -Hyrum
