Greg Stein <gstein@lyra.org> writes:
> > location) basically, he didn't want a node-revision's in-memory
> > representation to outlive its trail because other processes might
> > change the stored version of that node-revision -- so in order to make
> > changes to a node-revision, you had to read the node-revision from the
> > database and verify that (instead of just pulling up an old cached
> > copy of the thing), and then write back the modified node-revision in
> > the same Berkeley transaction.
>
> Euh... is there any good reason why it is cached? And now that we have a
> scratchpool, couldn't we just add a cleanup function there? Or maybe just
> allocate the dag node and the cached node revision *in* that scratchpool.
We used to cache it back when it held all the node's contents. It's
possible that this no longer needs to happen. Personally, I'd like
the to see the 'node_revision' member removed from the dag_node_t --
keeping it there is just begging for trouble.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 24 20:29:03 2003