subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan Zhakov <i...@visualsvn.com>
Subject Re: svn commit: r1716575 - in /subversion/trunk/subversion/libsvn_ra_serf: commit.c ra_serf.h util.c
Date Thu, 26 Nov 2015 08:53:57 GMT
On 26 November 2015 at 11:41, Bert Huijben <bert@qqmail.nl> wrote:
>> -----Original Message-----
>> From: Ivan Zhakov [mailto:ivan@visualsvn.com]
>> Sent: donderdag 26 november 2015 09:19
>> To: dev@subversion.apache.org; Bert Huijben <bert@qqmail.nl>
>> Subject: Re: svn commit: r1716575 - in
>> /subversion/trunk/subversion/libsvn_ra_serf: commit.c ra_serf.h util.c
>>
>> On 26 November 2015 at 11:05, <rhuijben@apache.org> wrote:
>> >
>> > Author: rhuijben
>> > Date: Thu Nov 26 08:05:36 2015
>> > New Revision: 1716575
>> >
>> > URL: http://svn.apache.org/viewvc?rev=1716575&view=rev
>> > Log:
>> > In ra_serf: when a to-be committed file has text and property changes to
>> be
>> > applied, pipeline both requests.
>> >
>> This could fail over HTTP/2 if both pipelined requests will be handled
>> by different worker threads: FSFS doesn't allow concurrent access to
>> transactions.
>
> I'm surprised to learn that. I would have guessed concurrent access was
> always part of the design of the fs layer, by the way we use it in mod_dav.
>
> I hope we can somehow lift that restriction, as improving commit performance
> over mod_dav is high on a few wish lists.
>
First of all I'm not sure that concurrent *writing* could speed up
commit: there is no fsync() calls when working with transactions. As
far I remember svn:// also waits for every TXN operation to complete
before sending next one, so svn:// and http:// performance should be
the same when working over high-latency network.

Another problem could be than TXN operations are have dependencies on
each other and order is very important.

-- 
Ivan Zhakov

Mime
View raw message