[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 18:54:24 CEST

Alan Grow <agrow@thegotonerd.com> wrote on 04/08/2005 11:43:20 PM:

> Thanks for the design info, that helps a lot. So under FSFS a checkout
> the latest revision takes O(lg(N)) on avg instead of O(N) as I had
> 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.
> One could certainly cook up a skip-delta scheme for this. Each
> path terminates in a full copy of the file. A commit overwrites this
copy, but
> not before a reverse delta is added behind it. Perhaps the real problem
> more of an architectural clash; I can't say because I'm not an svn
> It just seems to me that checkouts may not be as optimized for the
> case as they could be. As an svn admin & very interested follower of the

> project, I've heard "checkouts are slow" quite a lot, and know of at
least one
> large opensource project (open exchange) that have delayed their
migration to
> svn until things improve in that department.

Put on your Asbestos suit and head over to the dev@ list with your ideas

Seriously though, BDB essentially works the way you describe and checkouts
are slow for it as well. This is not the reason that Subversion checkouts
are slow. It is more based on what it is doing in the WC on the client.

Also, you are ignoring that there are other design constraints in place
here. The designers wanted to support a write-only repository and they
also wanted to minimize space usage.


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 18:57:42 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.