Greg Stein <gstein@lyra.org> writes:
> On Fri, Sep 19, 2003 at 11:45:04AM -0500, cmpilato@tigris.org wrote:
> >...
> > Log:
> > Here we go. A first step towards solving issue #1499 (the oh-my-gosh-
> > our-bdb-transaction-usage-is-horrible bug).
>
> Something that is related to the txn adjustment is the "undo" record
> usage. If we don't really have txn abort/commit, then the undo stuff
> doesn't make a lot of sense.
>
> 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.
Yep, already been over all this. "One thing at a time" -- we're
about to start rocking a pretty core library here. :-)
The one use of svn_fs__record_completion() is some protective code
that (I believe) Jim had in the filesystem code. And if I understand
the intent correctly (judging from the comments there around the usage
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.
We can evaluate the sanity of keeping or removing this at another time
though -- let's deal with the scarier issues first.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Sep 22 16:59:18 2003