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

Re: Merge error with SVN 1.8.0

From: Stefan Sperling <stsp_at_elego.de>
Date: Sat, 29 Jun 2013 13:18:16 +0200

On Fri, Jun 28, 2013 at 03:36:38PM -0700, Alexey Neyman wrote:
> [copying dev@ because I found what the issue is]
> Hi,
> Did some further investigation and it turns out that SVN1.8 client creates more
> connections to the server when performing 'svn merge' - exceeding the xinetd's
> default number of connections per source (10) and indeed, closing the connection on
> an unsuspecting client. After increasing the number of connections per source to
> unlimited, the merge went through.
> Here are some statistics:
> SVN 1.7, merge --reintegrate
> 13 connections total, 5 concurrent connections maximum
> SVN 1.8, merge
> 18 connections total, 11 concurrent connections maximum
> SVN 1.8, merge --reintegrate
> 5 connections total, 3 concurrent connections maximum
> So, it looks like the new code for automatic detection of "reintegration merges" in 1.8
> spawns a bunch of additional connections. So, the question is - what is the maximum
> number of connections that a client can create to a server? Does it depend on the size
> of the change? Size of the svn:mergeinfo?
> I am not comfortable leaving the server configuration at "unlimited", seeing that
> xinetd limit is a safety net against runaway client bringing down the server.

I'm not entirely sure how to estimate the largest number
of connections made by 'svn merge'.

Note that the number of connections also depends on the amount of
svn:externals involved in checkouts and updates. One new connection
is opened for each external.

You might be interested in Ivan's RA session reuse patch:
This will probably be in 1.9, so it won't help you now. But I still
thought it was worth mentioning since it will address your problem
in the long term.
Received on 2013-06-29 13:19:00 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.