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

Re: optimizing fsfs: reverse diffs?

From: Mark Phippard <MarkP_at_softlanding.com>
Date: 2005-04-08 17:03:24 CEST

Alan Grow <agrow@thegotonerd.com> wrote on 04/08/2005 10:44:39 AM:

> FSFS is great, but I'm a little worried about checkout slowdown,
especially
> as a project ages. Instead of reconstructing the current revision each
time
> from an ever-lengthening sequence of forward diffs, why doesn't FSFS
optimize
> for the common case and store the full current revision and a sequence
of
> reverse diffs? (Ala rdiff-backup: http://www.nongnu.org/rdiff-backup/.)
>
> I'll pack my bags & go to dev with this question if you think I
should. :)
> Thought I'd try here first though.

FSFS doesn't work quite the way you think. It uses something called
skip-deltas. The bad thing about reverse diffs is that the database has
to be constantly rewritten. FSFS wanted to support a permissions
structure where you only need to have enough permission to write a new
file. Existing files are in the database are NEVER updated after they
have been written. This also makes for a good incremental backup
solution.

The skip-deltas approach is a great compromise. It yields good
performance, and better space utilization. Read the design notes.

http://svn.collab.net/repos/svn/trunk/notes/skip-deltas

Mark

_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Apr 8 17:16:09 2005

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

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