Déploiement avec Capistrano & Subversion. Copie de travail verrouillée

Question

Je suis en train de déployer sur un serveur Debian avec Capistrano qui échoue en raison d'une copie de travail bloquée. Je rétréci à ceci:

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

Donc, si je lance:

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

Je reçois une erreur:

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

Nettoyer ne fait aucune différence. La même commande s'exécute correctement à partir du serveur. Quand je liste les fichiers dans 1234/je peux voir tous les fichiers de copie .svn et de travail.

Est-ce que quelqu'un peut me diriger dans la bonne direction pour résoudre ce problème? Comment savoir si la copie de travail est vraiment verrouillée? ne montre rien.

Answer 1

juste eu le même problème, passé environ une heure à essayer de comprendre ce qui se passe.

i remarqué la raison en regardant cette chaîne (celui avant d'entrer le mot de passe)

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

essentiellement j'ai commandé Capistrano déployer deux fois à un même serveur (myhost = 192.168.1.200) dans mon Capistrano fichier deploy) et il se verrouillait

espérons que cela aide quelqu'un.

Answer 2

Tout d'abord, vous devez faire attention à l'utilisation de l'extraction plutôt qu'à l'exportation vers une URL accessible au public. Si vous n'avez pas verrouillé les répertoires .svn dans Apache, vous ouvrez un trou de sécurité potentiel. Cela mis à part, est-il possible que Capistrano fonctionne comme un utilisateur différent qui n'a tout simplement pas les permissions pour mettre à jour ce répertoire?

Answer 3

L'erreur s'est produite en raison de problèmes d'autorisation de fichiers entre Mac OSX et Linux s'exécutant sur un partage Samba. Je ne peux pas me souvenir des détails exacts, mais les différents systèmes gèrent différemment les permissions sur les fichiers cachés, donc Samba utilise un travail que SVN n'aime pas. J'ai résolu le problème en migrant vers GIT.