On Wed, 2010-03-03, Bert Huijben wrote:
>
> > -----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).
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
>
Received on 2010-03-03 14:34:19 CET