Daniel Berlin wrote:
> Kamesh Jayachandran wrote:
>
>> Hi,
>>
>> After doing some research I have the following questions.
>> Why do we write 'path Vs mergeinfo string hash' to disk? Why not read
>> fs_node_prop for 'svn:mergeinfo'?
>>
>
> Because of the eventual goal some have to not store mergeinfo in the
> properties on the server.
>
>
>> From the comment I could understand that it is to avoid the reparsing
>> of 'svn:mergeinfo' property string.
>> But we do reparsing already for each and every path in 'svn:mergeinfo'
>> in index_path_merge_info.
>>
>> This transactions/<no>-<id>.txn/'mergeinfo hash file just reduces path
>> parsing not the rev parsing which is normally going to be very big as we
>> keep doing the merges.
>>
>> Offtopic:
>> Anyway observed the svn_fs_t* as seen from commit_body and
>> fs_change_node_prop are one and the same.
>> So introduced the 'apr_hash_t *minfo' to svn_fs_t's fsap_data, it
>> worked! Except for one segfault in merge_tests.py 16th TestCase.
>>
>> Not sure whether this step is correct or now.
>>
> No, you can't rely on them being shared.
> Really.
>
>
I had fixed that segfault too, is it not better to have them cached at
"svn_fs_t's fsap_data".
I mean creating the fsap_data->minfo in thread local storage that way
they can be safely shared across threads.
Anyway no issue with multi process.
Please clarify in case I misunderstood your point.
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 Fri Aug 25 19:20:08 2006