Conclusion: SVN's access address is set through the extranet, which is limited by the network upgrade, resulting in an unsuccessful SVN submission. Modified to intranet, or the release of restrictions enough to solve the problem ================================================================== Org.apache.subversion.javahl.ClientException:? 3ì?÷?ú????? á?????? Óе?l?? ￡
Svn:can ' t read from connection: remote host forced to close an existing connection
Today, there was a problem with the SVN plug-in for STS that checked in the modified code and popped up "Svn:can ' t read from connection: The remote host forced the shutdown of an existing connection."
Tried a lot of ways, some code can check in, some can not.
After that, you will not be able to back up and try again. Failed.
Connecting to the SVN library via TortoiseSVN failed,
Try to ping 192.168.0.XX intranet address, can ping pass c:\users\thinkpad>ping 192.168.0.XX
Pinging 192.168.0.XX with 32 bytes of data:
Reply from 192.168.0.XX: bytes =32 time <1ms ttl=63
Reply from 192.168.0.XX: bytes =32 time <1ms ttl=63
Reply from 192.168.0.XX: bytes =32 time <1ms ttl=63
Reply from 192.168.0.XX: bytes =32 time <1ms ttl=63
Ping Statistics for 192.168.0.XX:
Packet: Sent = 4, received = 4, lost = 0 (0% lost),
Estimated time, in milliseconds, for a round trip:
The shortest = 0ms, the longest = 0ms, the average = 0ms after the attempt, the problem remains.
After that, considering SVN I was configured through the extranet address, I tried to telnet the extranet connection and failed. Therefore, through the project folder on the right button, tortoisesvn-->relocate, the external network address to modify the intranet address, after the attempt, success.
Analysis reason: Because before the company's network has been reformed, should be some network's setting has made the change, caused the SVN submission to be unsuccessful.
TORTOISESVN update address under Windows:
