C. Michael Pilato wrote:
> 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.
>
>
It happens because we call 'base_txn_mergeinfo' indirectly.
Call chain upon commit in the order of call.
txn_vtable's commit_txn hook(svn_fs_base__commit_txn)
|
V
svn_fs_merge_info__update_index (available in libsvn_fs_util)
|
V
txn_vtable's get_mergeinfo hook(base_txn_mergeinfo)
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 2 17:18:23 2007