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

Re: Complexity of creating a new revision.

From: T'aZ <tazdev_at_punkass.com>
Date: 2005-10-23 19:34:47 CEST

On Sun, 23 Oct 2005 18:50:57 +0200
Miha Vitorovic <mvitorovic@nil.si> wrote:

> > the vector of trees is not stored as complete copies in the repository,
> > it's encoded as a series of "deltas"
> > so when you use the FSFS or the BDB backend, you have to read/adjust
> > O(log(n)) deltas (according to svn/trunk/notes/skip-deltas )
> > so this is *not* done in constant time, right ?
>
> Not as I understand it. To recreate the contents of a given revision, sure
> you need to go through all the diffs, to get it. But to create a copy of a
> given tree at revision X, all you need to do is "create copy of a tree at
> revision X", that is you create a new reference to the data, without
> actually copying or recreating that data. That will be done, when somebody
> tries to read the contents of this copy. I guess in the context of a *nix
> FS, this would be like a hard link to a directory.

yes, only a new reference must be created pointing to the data , but since this new reference adds a new revision, it must be encoded as a delta against a previous one (in the fsfs case) or some deltas must be recreated (in the bdb case)
no ?

-- 
T'aZ |Jabber:taz-007_at_jabber.org|GPG keyID:E051925D|http://taz.prout.be
*They that can give up essential liberty to obtain a little temporary
 safety deserve neither liberty nor safety.*  Benjamin Franklin 1759
*Beaucoup,vite,loin,mal.*  http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Oct 23 19:42:44 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.