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

Re: [PATCH][merge-tracking]diskfile merge info hash to in memory mergeinfo.

From: Kamesh Jayachandran <kamesh_at_collab.net>
Date: 2006-08-25 19:19:13 CEST

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

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.