Connections to SVN seem to reset often. When trying to commit, update or perform any other command that requires communication with the server, SVN often fails on the first try then works on the very next try without a problem. This happens on servers inside or outside of the MPT VPN.
Might be worth checking the logs on the svn server; could be a DNS server timing out (but returning the result later, so it's cached and fast on the next request).
This failing on the first attempt and succeeding on the second, does this happen sporadically or every single time you connect to svn?
Sporadically for me, at least, as I see this issue, too.
OS: Other → All
For me, it's almost every time when trying to update. Commits usually work fine, but occasionally they have the problem too.
We had some dns issues with MPT that may have been causing this problem. We fixed those last week. Let me know if you continue to notice these timeouts/failures.
They have been far less frequent since the bug was originally filed, however I do still have this happen sometimes.
I've had it happen to me twice over the past couple of days, which is a lot less than usual. I was going to try making all my commands verbose, so when something happened I might be able to help track it down, but SVN saw me coming: wclouser@khan-vm:~/public_html/remora$ svn up -v Subcommand 'update' doesn't accept option '-v [--verbose]'
On a suggestion from aravind, I added 10.2.74.16 to the hosts file on khan, and svn commands from khan have been doing great.
For those without access to the VPN, use 126.96.36.199 for the svn ip address. This bypasses the NS and goes straight to the host.
svn.mozilla.org now goes to 188.8.131.52 which should resolve whatever connectivity issues you were seeing.
separated svn from the NS, so connections are now going straight to the primary svn server. Please re-open if you continue to notice any problems with it.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.