Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

We have an nginx server which proxies to a standard set-up of Apache+SVN. The nginx set-up is a very simple proxy:

server {
    server_name svn.ourdomain.tld;
    location / {
        proxy_pass http://localhost:8080;
    }
}

Apache is set-up as follows:

<Location />
    DAV svn
    SVNParentPath /var/svn
    AuthType Basic
    AuthName "Authentication Required"
    AuthUserFile /var/svn/.auth
    Require valid-user
</Location>

...which allows us to access repositories using something like http://svn.ourdomain.tld/repo. We've been running this set-up now for about 2 years without issue.

Recently we've found that we need to check out one of the repositories onto the server itself, however whenever we do so it seems to break the repo. From that point on, it will only respond with a 301 Moved Permanently error.

We've tried:

Also tried bypassing nginx, and get the same error:

Checking out from a different machine works as expected until we attempt to check out on the server, after that it refuses with the same 301 error.

What is more confusing is that this repository server also hosts our HudsonCI server, which can pulls and builds our projects hourly. This leads us to suspect that it's the svn client which is causing an error in communication.

Its also very confusing that removing then re-creating the repo using svnadmin doesn't reset the error - the repo is still unavailable even though it's "new"! Restarting apache and subversion (svnserve) has no effect on this, or the original error.

Version information:

  • OS: 64-bit CentOS 4.2, 2.6.27 kernel
  • svn client: 1.4.2 (same for both server and remote clients)
  • svn server: 1.4.2
  • httpd: 2.2.3

UPDATE:

This also happens with svn export when run on the repo server. Ran from any other box/client, there isn't a problem. Here's the workflow, to help clarify the error:

  1. [~repo-server~]# svnadmin create {repo}; chown -Rf www:www {repo}
  2. [remote-client]# svn checkout http://svn.ourdomain.tld/repo
  3. [remote-client]# svn add file; svn ci -m ''
  4. [~repo-server~]# cd /var/www; svn export file:///path/to/repo/trunk ourproject
  5. [remote-client]# svn update fails with 301 error

I can also confirm that the hostname of the box doesn't have an effect here, which is very odd: whether or not svn.ourdomain.tld is added to /etc/hosts it still breaks - we thought it could be an issue with localhost routing, but that doesn't seem to be the case.

Are we missing something in the documentation which states you can't checkout a repo when the server is on the same box? How can we stop the repos becoming corrupt when we checkout locally?

share|improve this question

1 Answer 1

svn doesn't handle HTTP redirects (that's what the 301 error is), look where the redirects points to (wget, wireshark), checkout from there.

Also it is apache specific problem, the virtual host configuration can be breaking it.

share|improve this answer
1  
Doesn't explain why using the file:// protocol would also cause it to break. –  Phillip Oldham Oct 6 '10 at 16:14
2  
svn gives you 301 error on file:// ? That's weird –  Hubert Kario Oct 6 '10 at 16:18
    
Interestingly, curl shows the 301 is returned when the trailing slash is left off. Adding it fixes curl, but it still breaks locally. Remote checkouts (from a different box) work either way. –  Phillip Oldham Oct 6 '10 at 16:20
    
@Hubert - its always after a checkout attempt on the repo server; whether it's successful or not, subsequent co's from local and remote boxes fail. –  Phillip Oldham Oct 6 '10 at 16:21
    
That would suggest that the rewriting is broken somewhere (forces "/" at the end perhaps) –  Hubert Kario Oct 6 '10 at 16:24

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.