[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: Neels J Hofmeyr <neels_at_elego.de>
Date: Wed, 31 Aug 2011 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

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...

A new format doesn't solve the underlying separation -- unless it's niftier
than me.


Received on 2011-08-31 03:18:08 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.