[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: Daniel Berlin <dberlin_at_dberlin.org>
Date: 2005-04-08 18:56:56 CEST

On Fri, 2005-04-08 at 23:43 -0400, Alan Grow wrote:
> Mark,
>
> Thanks for the design info, that helps a lot. So under FSFS a
> checkout of the latest revision takes O(lg(N)) on avg instead of O(N)
> as I had assumed. Still, if you always stored the latest revision of a
> file in full & stored the transactions as reverse diffs, checkout
> latest would be an O(1) operation. Even better.

You've missed the important part of his response. :)
Doing this would require modifying the previous revision to be a diff
against the new head.

We don't want previous revisions to be modified, we want them completely
read-only and immutable.

This is also *much* better for things like rsync and friends, which now
can sync a repository by only transferring new files (whereas with your
scheme, you could have a significant number of modified existing
revisions).

> It just seems to me that checkouts may not be as optimized for the
> common case as they could be.

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 :)

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Apr 8 19:00:30 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.