[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: Julian Foad <julian.foad_at_wandisco.com>
Date: Wed, 03 Mar 2010 13:33:40 +0000

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

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