[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

The use of trails in svn_fs_base__commit_txn()

From: Ben Collins-Sussman <sussman_at_red-bean.com>
Date: 2006-01-10 18:51:22 CET

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

This is an archived mail posted to the Subversion Dev mailing list.