[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: pristine store design

From: Neels J Hofmeyr <neels_at_elego.de>
Date: Thu, 18 Feb 2010 03:01:05 +0100

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 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.

Received on 2010-02-18 03:01:45 CET

This is an archived mail posted to the Subversion Dev mailing list.