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.
> 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...
-Karl
--
www.collab.net <> CollabNet | Distributed Development On Demand
---------------------------------------------------------------------
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:00:46 2006