[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1715228 -/subversion/trunk/subversion/libsvn_ra_serf/util.c

From: Ivan Zhakov <ivan_at_visualsvn.com>
Date: Fri, 20 Nov 2015 12:12:14 +0300

On 20 November 2015 at 11:53, Bert Huijben <bert_at_qqmail.nl> wrote:
> Ack.
> Not pipelining, or not sending simultaneous/parallel requests if you don’t
> want to depend on the order in which they are received is the safest thing.
> And the current code can break even in http/1. Svnrdump even has special
> precautions for this even though I have no idea why it would see the
> problems it describes it has. (The editor drive is 100% from one http
> response)
> What we could do is replace the current assertion with a request on a
> completely different connection to retrieve the properties if we don’t have
> them in time… as a fallback mechanism to at least continue going. This also
> works for legacy servers if the first improvement is applied.
> I’m not sure if the current implementation has more problems… E.g. if
> revisions can also be received out of order.
> Going to a single report –that includes the revprops- for multiple revisions
> is a safe extension, that will improve in all cases: HTTP and HTTP/2 alike.
I understand that current is also unsafe, that's why I suggest go
single REPORT and disable pipeling for older servers. I'll add this to
my TODO list you agree that this approach makes sense.

> I will start looking in supporting priority scheduling anyway…. But that
> requires more work in other parts of serf first. (I can’t use the request as
> an argument while serf still thinks it can destroy and recreate requests at
> a different address at will as part of the auth handling)

Ivan Zhakov
Received on 2015-11-20 10:12:44 CET

This is an archived mail posted to the Subversion Dev mailing list.