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... A new format doesn't solve the underlying separation -- unless it's niftier than me. ~Neels
signature.asc
Description: OpenPGP digital signature
