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