[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: John Szakmeister <john_at_szakmeister.net>
Date: 2005-04-08 23:42:17 CEST

On Friday 08 April 2005 23:43, 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.
>
> One could certainly cook up a skip-delta scheme for this. Each
> skip-delta 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 is more of an architectural clash; I can't
> say because I'm not an svn developer.
>
> It just seems to me that checkouts may not be as optimized for the
> common 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.

The BDB version does something like this already... it stores the HEAD of
each branch as full-text. But, that has it's drawbacks too. Mainly, if
you use a lot of branches, you can increase the size of the repository a
little more significantly because of the extra full texts. Of course,
we've gotten complaints about the size of BDB repositories too... it's
all a trade off, but it's all been thought about. :-)

-John

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Apr 9 00:41:35 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.