On Tue, 2006-01-10 at 12:25 -0600, kfogel@collab.net wrote:
> > 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...
That last-minute changes which snuck in during my transaction's commit
are merged into my transaction at commit-time is an implementation
detail, and certainly not part of the expected behavior as viewed at an
API level. In other words, looking strictly at the svn_fs.h API,
there's nothing there that would make me *not* be completely surprised
to find that my failed-due-to-conflicts transaction was modified by the
commit process. BDB is doing the Right thing here; FSFS is not.
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Tue Jan 10 21:51:35 2006