On 07.07.2014 16:25, Ivan Zhakov wrote:
> On 27 August 2013 03:53, <stefan2_at_apache.org> wrote:
>> Author: stefan2
>> Date: Mon Aug 26 23:53:19 2013
>> New Revision: 1517733
>>
>> URL: http://svn.apache.org/r1517733
>> Log:
>> Following up on a suggestion by Ivan on @dev about a month ago.
>>
>> This is an initial draft plus completely untested implementation
>> for an SVN file API. Its implementation works around a few
>> inefficiencies and scalability issues with apr_file_t. See the
>> header comments for details.
>>
>> Tests will be added eventually and the code stabilized based on
>> the test results. To prevent accidental use in current production
>> code, the new API is only available if you define #ENABLE_SVN_FILE
>> in your code.
>>
> Hi Stefan,
>
> I told you multiple times that I'm against file handling sharing in
> Subversion code:
> 1. Operating already maintains shared state files. At least it could maintain
> 2. It very error-prone to maintain shared file handle state in user
> mode, because file handle may potentially have many hidden state and
> passing it from different code could create very nasty side effects in
> multi-threaded applications
>
> I'm also think that brain-dumping untested and not ideas to
> repository: it's very confusing for readers.
>
> So could you please revert your change given all reasons above.
>
> PS: AFAIK I suggested you to experiment with direct OS file API usage
> instead of APR if you think that apr_file_t is performance bottleneck.
I have to agree with Ivan here. If there is a problem with the
apr_file_t implementation, then the place to fix it is in APR, not in
Subversion.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com
Received on 2014-07-07 16:59:48 CEST