After chatting with kfogel, I have two concerns regarding our use of
trails in svn_fs_base__commit_txn(). We agreed that they were worth
mailing the list about.
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?
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?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 10 18:58:53 2006