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

Re: The use of trails in svn_fs_base__commit_txn()

From: Michael Pilato <cmpilato_at_collab.net>
Date: 2006-01-10 21:49:15 CET

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

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.