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

Re: merge-tracking: Intentional reading of merge info outside a BDB transaction?

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2007-03-31 05:13:44 CEST

Kamesh Jayachandran wrote:
> C. Michael Pilato wrote:
>> Today, I was poking thru the BDB code, and noticed the new public FS APIs
>> for merge tracking. As I dug into them a little bit deeper, though, I
>> saw
>> something that didn't seem quite right: base_txn_merge_info() doesn't
>> wrap
>> its read of the txn's proplist in a BDB transaction. Was that an
>> intentional deviation from the way svn_fs_base__txn_proplist() works
>> (even
>> though the two are super-similar in functionality)?
>>
>>
> Yes it is intentional.
> If we use 'svn_fs_base__retry_txn' instead of 'svn_fs_base__retry' it
> tries to open one more trail and hence aborts.
>
> 'begin_txn' in subversion/libsvn_fs_base/trail.c has the following comment,
> <snip>
> /* [*]
> If we're already inside a trail operation, abort() -- this is
> a coding problem (and will likely hang the repository anyway). */
>
> </snip>

base_txn_merge_info() is a vtable implementation of a public function, and
is not a trail-protected function. It should be able to call
svn_fs_base__retry_txn() just fine. If you're getting an abort() when coded
that way, it's because you're calling into an FS vtable function from some
other trail-protected function, which is both unnecessary and a violation of
the (admittedly undocumented) libsvn_fs_base API usage rules.

If the only intention here was avoiding an abort(), then the code is just wrong.

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on Sat Mar 31 05:13:55 2007

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