[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] Server-transmitted "final SHA1 checksums" (Was: "large number of large binary files in subversion")

From: Julian Foad <julian.foad_at_wandisco.com>
Date: Wed, 25 May 2011 10:21:29 +0100

On Tue, 2011-05-24 at 18:21 +0200, Branko Čibej wrote:
> 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.

The ref-count in the DB is an "internal" ref-count: that is, it only
counts the references that are present in the DB itself (in the NODES
table), and not logical references that the program might be holding in
its volatile memory. This was a decision in order to keep the design of
that subcomponent simple.

- Julian
Received on 2011-05-25 11:22:05 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.