SVNService gets tired, dies in middle of checkout

Our customer has a subversion repository to which we have recently added
well over a couple thousand 'file externals' properties (though we have removed
many of them as the files involved are binary files). The svn server
(SVNService.exe) is running on a Windows Server machine as a Windows service,
and we access the respository via: "svn://servername/..."

The problem we are seeing now is this: when we do a checkout or an update
from the root of the project, the SVNService fails, and must be restarted,
about two or three times before the checkout or update completes.

In the output of the checkout, for example, there are first a lot of:

 A dir1\dir2
 A dir1\dir2\file1

And then the externals:

 Fetching external item into 'dir1\dir2\file2'
 Updated external to revision 32273.

And then, the failure:

 Fetching external item into 'dir1\dir3\dir3\ntp.conf'
 svn: warning: Network connection closed unexpectedly

 svn: warning: Error handling externals definition for 'dir1\dir4\dir5\file3':
 svn: warning: Can't read from connection: An existing connection was forcibly
 closed by the remote host.

We find the network connection to the server machine is fine,
but SVNService has to be restarted. Within a few seconds of restarting
svnservice, the checkout is again able to fetch externals (until the
service fails again).

Our system looks like this:

-svn, version 1.6.1 (r37116) compiled Apr 9 2009, 14:52:44

-Size of the working copy: about 8.5 GB, 83,500 files, in 48,000 folders

-Size of the repository: 17.5 GB

-maximum depth of repository: about 8 levels.

Is this related to our use of externals? Perhaps we should do a checkout using

the --ignore externals option... but that would be defeating the purpose of

using the externals?

Thanks,

-john

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2355986

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-05-28 01:39:35 CEST