On 10 Jan 2006 12:25:59 -0600, kfogel@collab.net <kfogel@collab.net> wrote:
> Ben Collins-Sussman <sussman@red-bean.com> writes:
> > 1. The first time a trail is used in the commit process, it's to
> > fetch the root node of specific revision "close" (or equal) to the
> > youngest rev. The comment doesn't make any sense; it seems to
> > imply that the trail is somehow protecting us from the 'root'
> > changing, though it's not at all clear what it means. The trail
> > seems totally unnecessary to me, and indeed, FSFS just goes and
> > getches the root-node directly. Can we remove this trail?
> > Toss the comment?
>
> Yes, my feeling is fetch the node in a non-traily manner, and edit or
> toss the comment as appropriate.
Maybe I'll send a patch, then.
>
> > 2. The second time a trail is used in the commit process, it's to
> > isolate the merge() operation (whereby the transacion tree is
> > merged into the latest revision.) I'm assuming that fs_base does
> > this work in a trail so that if a CONFLICT error occurs, the
> > transaction tree merges can be undone. In other words, I suspect
> > fs_base returns the tree exactly as it found it. FSFS, on the
> > other hand, makes no such guarantee. If its merging attempt
> > fails, the transaction tree may be left full of edits.
> >
> > I'm not sure what our guarantees to callers are. Is FSFS not
> > being nice enough, or is fs_base being overly nice?
> >
> > Either way, it seems to not matter in practice. I'm guessing that
> > every caller of commit_txn() simply aborts the transaction if an
> > error is returned, so we've never noticed. Thoughts, concerns?
>
> Yeah, I don't have a feel for which is the "better" behavior here, but
> it sure would be nice if we were consistent. Our callers will no
> doubt change someday, and then we'd be in for a surprise...
>
My feeling is: let's just augment svn_fs_commit_txn()'s docstring to
say something like, "if an error is returned, the transaction is in an
indeterminate state, consider it useless." Our callers are already
aborting the txn anyway, but it would be nice to make this policy
'official'.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 10 21:41:50 2006