Despliegue con Capistrano y Subversion. Copia de trabajo bloqueada

Estoy implementando en un server Debian con Capistrano que falla debido a que bloqueó una copy de trabajo. Lo networkinguje a esto:

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

Entonces si corro:

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

Me sale un error:

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

La limpieza no hace diferencia. El mismo command funciona bien desde el server. Cuando enumero los files en 1234 / I puedo ver todos los files .svn y de copy de trabajo.

¿Puede alguien señalarme en la dirección correcta para resolver esto? ¿Cómo puedo saber si la copy de trabajo está realmente bloqueada? svn status no muestra nada.

Solo tuve el mismo problema, pasé aproximadamente una hora tratando de descubrir qué estaba pasando.

Me di count de la razón al mirar esta cadena (la antes de ingresar la contraseña)

  * 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: 

Básicamente orderé a Capistrano desplegar dos veces en el mismo server (myhost = 192.168.1.200) en mi file de implementación de Capistrano) y se estaba bloqueando

Espero que ayude a alguien.

En primer lugar, debe tener cuidado al usar el pago y envío, en lugar de exportarlo, a una URL accesible públicamente. Si no has bloqueado los directorys .svn en Apache, entonces abres un posible agujero de security.

Aparte de eso, ¿es posible que Capistrano se esté ejecutando como un usuario diferente que simplemente no tiene los permissions para actualizar este directory?

El error resultó ser causado por problemas de permissions de files entre Mac OSX y Linux que se ejecutan a través de Samba Share. No recuerdo los detalles exactos, pero los diferentes sistemas manejan los permissions de los files ocultos de forma diferente, por lo que Samba usa un trabajo que no le gusta a SVN.

Resolví el problema migrando a GIT.