On 26 November 2015 at 11:41, Bert Huijben <b...@qqmail.nl> wrote: >> -----Original Message----- >> From: Ivan Zhakov [mailto:i...@visualsvn.com] >> Sent: donderdag 26 november 2015 09:19 >> To: dev@subversion.apache.org; Bert Huijben <b...@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, <rhuij...@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