Hi, Today I've tested wandisco's 1.8 distro and thr issue doesn't happens.
The problem is only in CollabNet's binaries. Regards Eric Em 05/05/2014 17:45, "Eric Lemes" <ericle...@gmail.com> escreveu: > Hi, > > One more information about this issue. > > I've downgraded to 1.7 (wandisco 32 bits) server and didn't have the issue > anymore. > > 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. > > Regards > > Eric > Em 02/05/2014 18:18, "Eric Lemes" <ericle...@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 >> simple. >> >> 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 interface: >> >> - 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. >> >> Regards, >> >> Eric >> >