RE: pristine store design

> -----Original Message-----
> From: Neels J Hofmeyr [mailto:neels_at_elego.de]
> Sent: woensdag 3 maart 2010 20:26
> To: Greg Stein
> Cc: Stefan Sperling; dev_at_subversion.apache.org
> Subject: Re: pristine store design
>
> Two separate things are getting mixed up here.
>
> 1) The fact that storing (only) md5 in the DB introduces the need for
> locking where it would otherwise be lockless.

If we move the file in place from temp to final location, not overwriting
existing files (fixes Windows case), then retrieve file size and date, then

INSERT OR IGNORE INTO PRISTINE (..., ...) VALUES (..., ...)

You have enough synchronization for adding new files.

A reader won't notice that anything happens and a simultaneous writer will
do exactly the same thing, as the MD5, size and timestamp of the file in the
pristine store will be identical for both clients.

(This will fail for the case where one writes a compressed version and one
doesn't. But if you make the compressed files use another extension you can
detect this case by checking the affected_rows value of the INSERT and
delete the file afterwards)

The real problem is: how do you handle removing files from the pristine
store with this scheme?

Possible (too) Easy fix for 1.7: Make sure you have a depth infinity lock on
the entire working copy/working copy database.

        Bert
Received on 2010-03-04 08:32:24 CET