RE: svn commit: r1073366 - in /subversion/trunk: notes/wc-ng/pristine-store subversion/libsvn_wc/wc-queries.sql subversion/libsvn_wc/wc_db_pristine.c

> -----Original Message-----
> From: Julian Foad [mailto:julian.foad_at_wandisco.com]
> Sent: maandag 28 februari 2011 19:29
> To: Branko Čibej
> Cc: Subversion Development
> Subject: Re: svn commit: r1073366 - in /subversion/trunk: notes/wc-
> ng/pristine-store subversion/libsvn_wc/wc-queries.sql
> subversion/libsvn_wc/wc_db_pristine.c
>
> On Mon, 2011-02-28, I (Julian Foad) wrote:
> > On Sat, 2011-02-26, Branko Čibej wrote:
> > > On 26.02.2011 20:40, Ivan Zhakov wrote:
> > > > Btw I think it makes sense rename file to tmp directory in working
> > > > copy instead of pristines directory, since it could be crash/failure
> > > > between rename and delete. In this case pristines directory will
> > > > polluted with orphaned pristines.
> > >
> > > That works as long as the pristine store lives in the WC root, so yes.
> >
> > This seems to be a good plan. Thanks for the help. I'll do it right
> > away.
>
> Please see attached patch. (I might write a test or two before
> committing it or I might commit first.)

If you just created a file in the tempdir it will be scanned by virusscanners while you will just want to delete it directly. (Which might trigger an access denied and then a wait loop)

I think you can safely assume that the file won't be removed from the pristine twice at about the same time, so just using the sha1 as the filename should be pretty collision safe. (And the wait loop will catch the other cases)

Note that we might assume that Subversion opens files with FILE_SHARE_DELETE, but we can't assume that other programs -like virusscanners, file indexers, etc.- triggered by our disk i.o., do the same thing. Especially since using this share flag has a performance penalty and allowing files to be deleted/changed while open makes it harder to test your application for correctness.

        Bert
Received on 2011-02-28 19:48:49 CET