On 26 November 2015 at 12:11, Bert Huijben <b...@qqmail.nl> wrote: >> -----Original Message----- >> From: Ivan Zhakov [mailto:i...@visualsvn.com] >> Sent: donderdag 26 november 2015 09:54 >> To: Bert Huijben <b...@qqmail.nl> >> Cc: dev@subversion.apache.org >> 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: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. > > No, in svn:// the client sends out all the requests and only peeks the > connection to see if there is waiting data (an error) during commit. The > client > only waits for the server after the entire commit is completed. Not after > every txn operation. Yes, you are right. But such error handling will make connection unusable after error, is not it? And as far I remember ra_svn doesn't have code to reconnect if needed.
> > This is why 'in general' you get not identical error reporting on commits > when you use > svn:// (or svn+ssh://, etc.). In many cases the only failure you see is the > text from the > server as the client doesn't even know which file/directory failed during the > commit. > > With a bit of luck you receive errors a bit earlier than the final commit > step. But with > <= 1.9.0 this didn't work for svn+ssh:// on Windows at all. (We handled the > error for > not implemented as if no data was waiting) > Ouch. I think it's just an example that async/delayed error handling is very tricky. -- Ivan Zhakov
