Great, moving forward fast on pristine design questions! The one thing left now is: > Can someone explain a motivation for even creating a database row before > the pristine file is moved into place in the pristine store? I currently > don't see why it can't be way simpler. > > (And, if it is necessary, how does a client deal with encountering a > pristine table row that has a SIZE==null? Idle a bit and try to wait for > the hypothetical other client process to finish? Discard and start > fetching the pristine, possibly again?)
We will only write/store to the pristine tempdir and then move into place. There will be no state "busy writing". Is there a different motivation left for the special case SIZE==null? The rest of the relevant stuff reposted below. ~Neels Neels J Hofmeyr wrote: > Greg Stein wrote: >> The schema is designed to *allow* for faulty files. The faulty file >> will NOT be used because SIZE==null in the database. >> >> If the file is successfully written, *then* we store a value into >> SIZE, indicating the file is present and correct. >> >> Of course, if you're overwriting a pristine file, then you better >> store SIZE==null before you begin writing. > > stsp and I have been discussing this a bit. I can't really see why > indicating a null size in the PRISTINE table is necessary. Our discussion > ended here: > > If we always write (copy) a pristine to a tempfile in the pristine tempdir > first and then move it into the final pristine file location, there either > *is* a complete pristine file, or there *isn't* one at all. (assuming atomic > 'mv' within the same filesystem device. *can that be assumed??*) > > It's not difficult to prevent one client from wanting to install the same > pristine twice within the same code path. > > To prevent two concurrently running clients from installing the same > pristine twice, a file lock seems more appropriate (with one wc.db per WC, > benefit of even that is debatable, but with one wc.db per user that might be > good). > > Either way, a pristine can only have one specific content -- it does not > really matter that much if one client overwrites it just after the other > created it.
signature.asc
Description: OpenPGP digital signature
