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

Re: [patch] revprop packing for fsfs

From: Hyrum K. Wright <hyrum_at_hyrumwright.org>
Date: Wed, 20 May 2009 21:40:18 -0700

On May 20, 2009, at 2:40 AM, webpost_at_tigris.org wrote:

> I won't criticise SQLite, but if there was a case for keeping the
> flat file system wouldn't a simple solution be to write modified
> revprops as a single file, and mark the revprop in the packed file
> as obsolete?
> Then reading a revprop reads the packed file as normal, but if the
> flag is set, read the revprop file that will be found on disk.
> A regular pack operation will then recombine the revprop into the
> packed file.
> Just my 2p, but if SQLite gives more functionality or is just faster
> - then I'm well happy with that!

Still haven't had time to review the patch, though I have time to do
some drive-by kibitzing. :)

Disks have improved vastly since Subversion debuted several years
ago. When it first came out, we spent a lot of time optimizing disk
accesses, on both the client and server. (Incidentally, this led to a
lot of mess in the working copy library, precipitating the current
rewrite known as wc-ng.)

The increase in disk performance means that we can sacrifice a little
bit of performance, for space and maintainability considerations.
Subversion should be in the business of doing version control, not
worrying about low-level file storage formats. Using a separate
library to manage the on-disk formats let's us concentrate on solving
version control problems. There isn't anything special about sqlite
per se, it's just the most convenient choice for the time being.

That's probably more than you'd like to hear, it's something I've been
thinking about recently, so it all spilled out. (And yes, Paul, I'm
still planning on reviewing the revprop-sqlite patch. Where did I put
those tuits?)


Received on 2009-05-21 22:13:00 CEST

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