One more information about this issue.
I've downgraded to 1.7 (wandisco 32 bits) server and didn't have the issue
Both Jenkins and RapidSVN working well. I'll try wandisco's 1.8 32 bits and
CollabNet's 1.8 32 bits to see if the issue persists.
Em 02/05/2014 18:18, "Eric Lemes" <ericlemes_at_gmail.com> escreveu:
> Dear Subversion developers,
> First I'd like to thank you for this great peace of success. I'm a user
> since the 1.4.x version in a lot of big and complex teams, allways with
> sucess. SVN is allways my first choice when I need something reliable and
> Recently, I'm setting up an environment, and got stucked with an issue.
> Here goes the description:
> Server Environment:
> - Windows 2008 RC 2 Server 64 bit
> - CollabNet Subversion Edge 4.0.6 (Subversion 1.8.8) plain vanilla
> - Integration with Active Directory through LDAP
> Description of the issue:
> I've been using the server with version 4.0.2 without big problems. After
> adding a lot of SQL Server Stored procedures (maybe the issue is a curse!)
> to the repository, ~100Mb, I couldn't update gracefully any of my working
> copies anymore.
> When checking out or updating the working copy using command line client
> (subversion 1.8.3) I receive the following error:
> svn: E730053: Error retrieving REPORT: An established connection was
> aborted by the software in your host machine.
> Jenkins' SVNKit SVN plugin also crashes, with the error:
> org.tmatesoft.svn.core.SVNException: svn: E175002: REPORT
> /svn/BuildUtils/!svn/vcc/default failed
> RapidSVN: Same behavior.
> After some tweaks on the clients, updating several times, I can update the
> working copy, but I don't think it is a normal behavior.
> I did some searches on google and dev list and only found an old issue
> about this behavior with https. I'm using plain http because this is an
> internal repository.
> Other important stuff: CollabNet has some options on their easy mode admin
> - Allow; support all-inclusive responses to REPORT requests, if client
> supports them.
> - Prefer; notifies clients that bulk responses are preferred over multiple
> individual GET/PROPFIND requests.
> If I disable both, none of the clients can update the working copy. If I
> enable all of them, the command line svn 1.8.3 updates without any issues
> but the other clients (Jenkins and RapidSVN) still don't work.
> This makes me think that the problem is somewhat related to an
> optimization of the REPORT request that could possibly break the old
> GET/PROPFIND behavior.
> I appreciate any help. My CI Server is broken right now because of this
> issue. Red lights makes me very sad.
Received on 2014-05-05 22:46:29 CEST