> -----Original Message-----
> From: Stefan Sperling [mailto:stsp_at_elego.de]
> Sent: maandag 1 maart 2010 19:32
> To: Julian Foad
> Cc: Neels J Hofmeyr; Greg Stein; dev_at_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).
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
Received on 2010-03-03 13:55:09 CET