> -----Original Message-----
> From: Branko Čibej [mailto:brane_at_xbc.nu] On Behalf Of Branko Cibej
> Sent: dinsdag 24 mei 2011 18:22
> To: dev_at_subversion.apache.org
> Subject: Re: [PATCH] Server-transmitted "final SHA1 checksums" (Was: "large
> number of large binary files in subversion")
>
> On 24.05.2011 17:53, Arwin Arni wrote:
> >> I was hoping to slip in
> >> support for avoiding those text transfers altogether where possible.
> >> But I
> >> ran into the obvious problems with the editor interface. (Also, I
> >> became
> >> concerned about the possibility of a race condition in the pristines
> >> table
> >> -- client says "Yep, I've got that text already!", edit continues while
> >> simultaneously in some other part of the tree that text is removed, edit
> >> goes to reference the supposedly redundant checksum and it ain't
> >> there no mo'.)
> >>
> >
> > Can't we increase the ref-count of the pristine node on getting the
> > <add-file...> element... this way, we need not worry about a parallel
> > <delete-file..> (IIUC delete-file will only reduce the ref-count, and
> > the actual removal of the pristine node is taken care of after the
> > entire editor drive.. atleast.. this is the way it is in my head)
>
> <add-file> ... inc(refcount) ... commit ... ^C .... eep!
>
> In other words, 'tain't that simple ... on the other hand, the worst
> that can happen is that an unused pristine never gets removed from disk.
To resolve this and similar problems we defined that we are not allowed to remove pristines with refcount zero until there are no more workqueue items, and nobody else has a working copy lock.
(During update the only reference to a pristine is in memory. In some other cases the only reference might be in a skel in the workqueue).
So no need to update the refcount.
Bert
Received on 2011-05-25 16:43:33 CEST