Jayway Team Blog » dns http://blog.jayway.com Sharing Experience Tue, 07 Feb 2012 10:49:54 +0000 en hourly 1 http://wordpress.org/?v=3.3.1 Solving 403 problems with Sourceforge Subversion http://blog.jayway.com/2007/01/13/solving-403-problems-with-sourceforge-subversion/ http://blog.jayway.com/2007/01/13/solving-403-problems-with-sourceforge-subversion/#comments Sat, 13 Jan 2007 16:54:42 +0000 Ulrik Sandberg http://blog.jayway.com/?p=177 After having had severe problems when committing to the Sourceforge Subversion repos, I stumbled upon what appears to be the solution. The problem was that in the middle of a commit, one file or directory would fail with a 403 (permission denied). In desperation, I would chop up the change set and commit little pieces at the time, until only the ones with problems remained. I would then perform desperate unnamed actions with these until they eventually were committed. Pretty nerve-wrecking, time-consuming, and unproductive stuff. The worst part is that if you split the change set, you could end up splitting a move operation, which is basically a copy and a delete. Say that you commit the delete operation successfully first. Then you try to commit the copy, which will fail with a 404 (not found), since the stuff it tries to copy has been deleted. There are ways around it, but I won't describe them here. Horrible stuff.

I had seen somewhere that you could get the 403 error if you were using SSL (which I was) and the Sourceforge server svn.sourceforge.net. The correct server is the PROJECTNAME.svn.sourceforge.net, where PROJECTNAME in my case was springframework. So the correct URL to use is https://springframework.svn.sourceforge.net/svnroot/springframework/. This meant changing the checkout URL, which Subversion can do on an already checked-out working copy, using the switch command. Cool. When I tried this, it failed because it couldn't find the new server. The problem was that the DNS servers I was using at some point didn't find this server, and probably cached this negative hit. Eventually I found a DNS that could locate this server and performed the switch. Things have been working much better since.

Using the incorrect server, which most likely is a proxy server of some sort, could possibly have resulted in different physical servers being used for different requests during the Subversion transaction. It's not allowed to perform a svn copy operation between repositories. You'll get a 403 if you try it. Perhaps that rule applied to my situation as well.

]]> http://blog.jayway.com/2007/01/13/solving-403-problems-with-sourceforge-subversion/feed/ 0