> From: Ben Collins-Sussman [mailto:sussman@collab.net]
>
> 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.
>
Err, It's not like you're storing representations in memory. Just
NodeRevisionPKs, and a directory tree in memory. I suppose the tree
could get fairly large, but it seems like a useful space/time trade off.
> 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.
>
Nobody said performance induced changes were fun.... :)
> Just food for thought.
Yummy....
Besides, I just point out the issues, I don't schedule the work. :)
Post 1.0 is fine by me.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 29 06:07:15 2002