Deploying with Capistrano & Subversion. Working copy locked

Question

I'm deploying to a Debian server with Capistrano which fails due to locked a working copy. I narrowed it down to this:

svn checkout http://myrepo.net/mysite/tags/1.0 /var/www/mysite/releases/1234

So if I run:

cap invoke COMMAND='svn checkout http://myrepo.net/mysite/tags/1.0 /var/www/mysite/releases/1234'

I get an error:

svn: Working copy '/var/www/mysite/releases/1' locked

Clean up makes no difference. The same command runs fine from the server. When I list the files in 1234/ I can see all the .svn and working copy files.

Can someone please point me in the right direction to resolve this? How do I tell if the working copy is really locked? svn status shows nothing...

Answer 1

Firstly, you need to be careful with using checkout, rather than export, to a publically accessible URL. If youi haven't locked down the .svn directories in Apache then you open up a potential security hole.

That aside, is it possible that Capistrano is running as a different user that simply doesn't have the permissions to update this directory?

Answer 2

just had the same problem, spent about an hour trying to figure out what's happening.

i noticed the reason while looking at this string (the one before entering the password)

  * executing "svn checkout -q  -r422 svn://192.168.1.100/ /var/www/myhost/releases/20091102144836 && (echo 422 > /var/www/myhost/releases/20091102144836/REVISION)"
    servers: ["192.168.1.200", "myhost"]
Password:

basically i ordered capistrano to deploy twice to same server(myhost=192.168.1.200) in my capistrano deploy file) and it was locking itself

hope it helps someone.

Answer 3

The error turned out to be caused by file permission issues between Mac OSX and Linux running over a Samba Share. I can't remember the exact details but the different systems handle permissions on hidden files differently so Samba uses a work around that SVN doesn't like.

I solved the problem by migrating to GIT.