mark benedetto king <mbk@lowlatency.com> writes:
> On Mon, Nov 10, 2003 at 08:57:55PM -0600, C. Michael Pilato wrote:
> >
> > The new svn_fs_cleanup_txn() would always resume cleanup from wherever
> > it left off, and always leave enough pointers around so that if
> > something goes wrong, the cleaup attempt can be re-tried/continued
> > later. In other words, it leaves no dangling nodes, doesn't lose
> > references to copies before the copies themselves are gone, etc.
>
> This may be even harder than it sounds, if you want to have fixed
> upper bounds on your txn size (which is the whole point of the
> change).
No, actually, this shouldn't be that difficult. The removal of
mutable nodes can be done bottom-up, one trail-per-path. The removal
of changes is a single Berkeley call to delete all the stuff
associated with the transaction ID. The removal of copies is a little
uglier, and involves, per-trail, doing:
1. Read the txn, and pick the first copy from its copies list.
2. Remove the copy.
3. Write the txn, with its copies list absent that first copy.
Fortunately, not many copies happen in a single transaction, usually.
> Or perhaps is optionally harvested as part of an "svntunefs" run.
I dunno. Deltification (and other suggested operations that could be
part of 'svntunefs') isn't about correctness -- it's about us doing
our best to be nice to the user's hard disk space. :-) But cleaning up
(or at least marking as dead) transactions that a user asks to be
aborted is a correctness issue, because failing to do this is just
*asking* for something terrible to happen.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 11 16:02:55 2003