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

Re: svn_fs_link: incompatibility with new NodeRevId schema?

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2002-05-29 05:22:42 CEST

Karl Fogel <kfogel@newton.ch.collab.net> writes:

> "Bill Tutt" <rassilon@lyra.org> writes:
> > If there isn't a technical reason to have the data in the repository,
> > then it's a useless time drain to stick it there. The tree should just
> > be constructed in memory, and never ever be committed to the repository.
>
> That would be a good optimization, yeah. Not sure it needs to be
> pre-1.0, though, and the code will get a bit more complex on the
> repository side if we change this, I'll bet...

Yeah, definitely a post-1.0 thing. I hypothesize, however, that it
won't be a simple matter of "just make dir_delta be able to compare a
disk-tree with an in-memory tree." Historically, gstein has had big
objections to holding trees entirely in memory (such as svnlook
does)... that approach just doesn't scale well.

Instead, we'd need to find a different memory representation of the
client's report -- maybe one that looks like the client's report
itself (i.e. only describing *differences* in working revisions,
rather than representing every tree node explicitly). Either that, or
somehow allow pieces of a client report to be piecewise 'pushed' at an
alternative dir_delta interface. Hoo.

Just food for thought.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 29 05:25:59 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.