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: http://svn.haxx.se/dev/archive-2013-06/0292.shtml http://subversion.tigris.org/issues/show_bug.cgi?id=3763 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.