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

Re: FSFS successor ID design draft

From: Daniel Shahaf <danielsh_at_elego.de>
Date: Wed, 31 Aug 2011 13:39:23 +0300

Neels J Hofmeyr wrote on Wed, Aug 31, 2011 at 03:17:26 +0200:
> On 08/30/2011 06:34 PM, Hyrum K Wright wrote:
> > In reading through this, as well as the discussion in IRC, I'm once
> > again wondering why we're bolting this stuff onto the outside of FSFS
> > rather than rethinking the entire FS problem (along with things like
> > obliterate and move-to storage and ...). I realize we can't do
> > *everything*, but these feels strangely like libsvn_wc from 5 or 6
> > years ago. Is there a compelling reason to reinvent the database?
> I know nothing of other extensions to the fsfs database, but this is how my
> thought process early-outed from suggesting an all-new fsfs db because of
> successors:
> A large part of FSFS should be read-only, grow-at-the-end-only, so that we
> don't need to lock out readers while writing. However, successors are little
> bits of info *later* added to random spots of the big read-only part, like
> dusty strings continuously growing off of the impenetrable wall of
> revisions, as new solid revision bricks sprinkle successor ids from the top.
> No matter how we wriggle it, the successors will probably always be stored
> separately, of sorts bolted on to the RO part...

I don't follow. Storing a noderev's successors in a file named after
the noderev's id would be append-only; the problem here is that we'll
have tons of writeable files, not that the writeable files won't be

> A new format doesn't solve the underlying separation -- unless it's niftier
> than me.
> ~Neels
Received on 2011-08-31 12:40:36 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.