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

[Daniel Berlin <db...@dberlin.org>]

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.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

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

[Kamesh Jayachandran <ka...@collab.net>]

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

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

[Kamesh Jayachandran <ka...@collab.net>]

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.
>
>   
You mean change_merge_info hook of root_vtable_t? (Which I could not see 
anyone consuming) on commit from the client manged 'mergeinfo'?


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org