On Wed, 2010-03-03, Bert Huijben wrote: > > > -----Original Message----- > > From: Stefan Sperling [mailto:s...@elego.de] > > Sent: maandag 1 maart 2010 19:32 > > To: Julian Foad > > Cc: Neels J Hofmeyr; Greg Stein; dev@subversion.apache.org; Bert Huijben > > Subject: Re: pristine store design > > > > On Mon, Mar 01, 2010 at 06:14:33PM +0000, Julian Foad wrote: > > > On Thu, 2010-02-18, Neels J Hofmeyr wrote: > > > > 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. > > > [...] > > > > > "Simultaneous or multi-threaded clients" would be my first reaction to > > > that particular question. > > > > If two threads write to the same pristine, the content written > > will be the same (except in case of a SHA1 checksum collision > > which we choose to ignore). So, thread 1 writes to a tempfile, and > > when it's done, it moves the tempfile into place. The new filename > > of the tempfile being based on the SHA1 sum of the written content. > > If thread 2 does the same concurrently, the end result will be the > > same -- the file will only exist once at its SHA1 sum name. > > On posix, when using svn_io_rename_file() this would be true and this would > be pretty safe. > > On Windows you get an access denied (bad) and a 15 second delay retrying the > move (worse).
That's what svn_io_rename_file() does, but for cases like this we should (write and) use a different rename function that expects no file to exist at the target path, and that returns immediately if there is a problem. - Julian > So we should try to avoid overwriting existing files here. (I would guess > that tools like rsync and incremental backusp also like that we don't change > the date of these files) > > > Of course, writing the same pristine more than once is redundant. > > So we could try to optmize this redundancy away. But I don't think > > it is worth it. If you're only talking about threads within a single > > See ^^^. > > Bert >
