[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: Kevin Puetz <puetzk_at_puetzk.org>
Date: 2005-04-10 08:51:01 CEST

Alan Grow wrote:

> On Fri, Apr 08, 2005 at 12:56:56PM -0400, Daniel Berlin wrote:
>> We don't want previous revisions to be modified, we want them completely
>> read-only and immutable.
> The intent of this makes a lot of sense. While I don't see that previous
> revisions would need to be "redeltified" under a
> reverse-diff-back-from-HEAD scheme, it's true that their delta chain
> changes as HEAD changes. Apparently, this must really matter under the svn
> client-server model.

Not at all; the deltas sent to the client are recomputed anyway. In fact,
the bdb backend already does it the other way around (with the fulltext at
HEAD and a skip-delta chain going backwards).

However, this means that bdb is:
 * less space-efficient (any files modified in a branch end up with their
own fulltext at the branche's HEAD)
 * requires fancy transaction machinery to safely redeltify the previous
revisions (which makes it not work on network drives)
 * requires read-write access for read-only operations (such operations
still have to participate in the transactions)
 * is not as backup-friendly (with fsfs, one can bring the backup up-to-date
by just copying in the new revisions - existing files are never altered).

All that said, it is perhaps faster at checkouts for this reason, and having
all that transaction machinery makes it easier to do other indexing
optimizations as well (though I don't know what else is actually
implemented). If you want it, use it - it's been there since 1.0 :-)

>> When somebody actually comes up with a case where the majority of the
>> checkout time is being spend trying to run down skip-deltas for the
>> HEAD, i'd be concerned.
>> This never really is the case, though, so it's all just talk. The
>> slowdown is not here, move along :)
> You called me on it--I've done no profiling myself & have no numbers, only
> vague accusations. :) Just wanted to see if something like this has been
> considered. I can tell it has--thanks to you, Daniel, & Mark both.

I would suspect most of the slowdown in checkout is writing all the WC stuff
twice (the checkout and the text-base) and beating on little files in .svn
(which some filesystem's aren't particularly good at). But I don't have any
hard numbers either.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Apr 10 08:53:28 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.