On 08/01/2011 04:17 PM, Stefan Sperling wrote: > On Mon, Aug 01, 2011 at 03:04:38PM +0200, Neels J Hofmeyr wrote: >> - but on moves and reverts, the op_depth==0 row needs to be updated. So >> - the op_depth==0 rows' moved-to columns can be corrupted by interrupted >> operations. Yet this is easily remedied by a revert, clearing that column. > > Not sure what you mean here. In what way could columns become corrupted? > > Interruptions only happen on a higher level than individual column updates. > We wrap most (all?) operations that run multiple statements in sqlite > transactions -- see the various *_txn() functions in wc_db.c. > Either all SQL statements in such functions fail or they all succeed.
Of course. Forget that point of mine. > > So if an op_depth==0 row has a non-NULL moved-to relpath column > the relpath was inserted by a successful operation. > >>> Also, clear moved-to relpaths from the BASE tree during 'revert' so >>> we don't leave phantom moved-to information in the DB (are there any >>> other places where we need to clear it?). >> >> ^ here would be the remedy to any interrupted operations involving moved-to. >> And at the same time this update of op_depth==0 rows during revert was not >> necessary before this patch. > > It wasn't necessary because it was cleared by the existing revert code. We had to add to the recursive revert code AFAIR > I.e. this part of the required maintenance happened to be performed by > existing code. But that doesn't mean less maintenance. We need to maintain > moved-to data either way. I think it is easier to manage it in op_depth==0. > > Because of the transactional nature of our DB operations there are > only two kinds of inconsistencies we have to worry about, at a fairly > high level: so true. So pretty much my only concern is: do we want to avoid modifying the op_depth==0 nodes? ~Neels
signature.asc
Description: OpenPGP digital signature
