undo records (was: svn commit: rev 7096 - in trunk/subversion: libsvn_fs tests/libsvn_fs)

On Mon, Sep 22, 2003 at 09:57:50AM -0500, C.Michael Pilato wrote:
>...
> >
> > Looking into the problem, I see that we do not have a *single* call to
> > svn_fs__record_undo(). Also, we only have one call to record_completion,
> > called from dag.c to "uncache a node revision". I have no idea what that
> > is doing and why, but if we can eliminate that call from dag.c, then we
> > can completely eliminate the undo logic and simplify the system.
>...
> 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 can evaluate the sanity of keeping or removing this at another time
> though -- let's deal with the scarier issues first.

Sure. Just following up to clarify/expand. Maybe somebody can provide a
patch while you guys are busy :-) (especially if we hash out the desired
approach here).

Cheers,
-g

p.s. GAT: even though these may be "neat", they aren't used, so should be
removed; there shouldn't be "features" without a specific need.

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org