Erreur de copie de travail verrouillée dans tortoise svn lors de la validation
J'utilise Tortoise SVN pour mettre à jour et valider les modifications apportées au référentiel sur le serveur chaque fois que je modifie ma copie de travail. Mais à partir de quelques jours, je ne suis pas en mesure de valider les modifications et le message d'erreur suivant s'affiche chaque fois que j'essaie de valider.
Working copy 'C:\Program Files\EasyPHP\www\project\php' locked.
'C:\Program Files\EasyPHP\www\project' is already locked.
J'ai essayé de déverrouiller le dossier en faisant un clic droit dessus et en sélectionnant Tortoise SVN> Libérer le verrouillage, il est indiqué
Il n'y a rien à débloquer. Aucun fichier n'a de verrou dans cette copie de travail
Quel pourrait être le problème?
Pas de problème ... essayez ceci:
- Aller au dossier SVN de niveau supérieur.
- Faites un clic droit sur le dossier (qui contient vos fichiers svn)> TortoiseSVN> CleanUp
Cela résoudra sûrement votre problème. Je l'ai fait beaucoup de temps ... :)
Remarque. Assurez-vous que l'option "Casser les verrous" est sélectionnée dans la boîte de dialogue Nettoyage.
La réponse acceptée n'a pas fonctionné pour moi. Pour résoudre ce problème, j'ai dû faire un clic droit sur le fichier qui était verrouillé, sélectionnez repo-browser. Cela a ouvert une fenêtre contextuelle avec les fichiers tels qu'ils se trouvent sur le serveur SVN. J'ai ensuite cliqué avec le bouton droit sur le fichier verrouillé et sélectionné break lock.
Lorsque j'ai fermé le navigateur de référentiel, je pouvais enfin valider avec Explorer!
- Faites un clic droit sur le dossier.
- TortoiseSVN-> Vérifiez les modifications.
- Cliquez sur le bouton Vérifier le référentiel.
- Verrouillage sur tous les fichiers retournés.
J'ai rencontré ce problème aussi. Pour certains, je tiens à souligner que si le système est verrouillé, vérifiez auprès de votre équipe. Un membre de l'équipe peut avoir certaines choses bloquées parce qu'il y travaille (cela permet aux développeurs de travailler sur des choses sans que d'autres ne viennent et essaient de travailler aussi sur le même contenu). Si tel est le cas, le déverrouillage puis la mise à jour risquent de perdre des données pour le développeur qui les a verrouillées.
Dans cet esprit, je craignais que l'option de "nettoyage" ne modifie ma copie de travail ou ne supprime des informations du niveau Repo de Subversion. Ce n'est pas le cas. La réponse a fonctionné pour moi. Le mien est devenu verrouillé lorsque j'ai cliqué sur Annuler au milieu d'une mise à jour. J'ai fini par retirer certaines de nos branches et je n'avais pas besoin de ce matériel, alors j'ai appuyé sur Annuler. Ma copie de travail est devenue verrouillée. Je ne pouvais trouver aucun document apparaissant comme "verrouillé" lorsque j'utilisais la commande "Libérer le verrouillage". Cela m'a laissé perplexe et après une lecture rapide (et ce fil), j'ai tenté la commande "nettoyage". Après un nettoyage, mon problème a été résolu et plus rien n’était verrouillé.
source: http://tortoisesvn.net/docs/nightly/TortoiseSVN_en/tsvn-dug-locking.html
Il existe plusieurs significations de "verrou" dans SVN et certaines de ces réponses qui parlent de "verrou de rupture" ou d'un coéquipier détenteur d'un verrou n'utilisent pas le sens pertinent pour la question d'origine. Cette question concerne les "verrous de la copie de travail" (c’est-à-dire qu’ils sont tout à fait locaux par rapport à la copie de travail sur votre ordinateur et qu’ils n’ont rien à voir avec le fait que vous ou vos coéquipiers détiennent un verrou/un contrôle sur un fichier). La réponse acceptée par MicroEyes fait référence à l'utilisation correcte et constitue votre meilleure option lorsque cela se produit.
Si un nettoyage ne fonctionne pas, vous devrez peut-être extraire une nouvelle copie de travail du projet. Si vous avez des fichiers modifiés non validés, vous devez les copier sur la nouvelle copie de travail afin de ne pas perdre vos modifications.
Voir cette page dans la documentation Tortoise SVN pour une description des trois utilisations de "lock": http://tortoisesvn.net/docs/nightly/TortoiseSVN_en/tsvn-dug-locking.html
Extrait (soulignement ajouté):
Les trois significations de "verrouiller"
Dans cette section, et presque partout dans ce livre, les mots "verrouiller" et "verrouiller" décrivent un mécanisme d’exclusion mutuelle entre utilisateurs afin d’éviter des commits contradictoires. Malheureusement, Subversion et, par conséquent, ce livre doivent parfois être concernés.
Le second est le verrou de la copie de travail , utilisé en interne par Subversion pour éviter les conflits entre plusieurs clients Subversion opérant sur la même copie de travail. En général, vous obtenez ces verrous chaque fois qu'une commande telle que update/commit/... est interrompue à cause d'une erreur. Ces verrous peuvent être supprimés en exécutant la commande de nettoyage sur la copie de travail, comme décrit dans la section intitulée "Nettoyage".
...
Je ne savais pas du tout que le fichier contenait le verrou.
- Je suis allé au dossier de plus haut niveau
- Cliquez sur nettoyage et aussi coché parmi les méthodes de nettoyage -> Pause des verrous
Cela a fonctionné pour moi.
J'avais essayé diverses choses, y compris "Nettoyer" dans les sous-répertoires inférieurs. Enfin, j'ai essayé de mettre à jour le dossier de niveau supérieur. Rien. Ensuite, j'ai lu le conseil "Nettoyer le niveau supérieur". J'ai essayé ça. La partie nettoyage a réussi, mais le verrou est resté. Ma solution consistait à revenir au niveau supérieur, nettoyer, puis nettoyer chaque dossier rouge (!) Dans lequel je pouvais accéder au détail. Après tout était "nettoyé", la mise à jour a parfaitement fonctionné. L'astuce "break lock" semble bonne aussi, à l'exception du fait qu'un membre de votre équipe pourrait avoir un verrou légitime sur les choses.
J'ai réussi à me verrouiller hors d'un fichier en svn - je ne sais pas comment - mais quand j'ai essayé de (re) récupérer le verrou (Tortoise montrait l'option "Get Lock" pour le fichier), elle se plaignait déjà du fermer à clé. J'ai essayé de supprimer le fichier et de valider le changement de répertoire - même résultat. J'ai essayé CleanUp (y compris l'actualisation de la superposition), mais cela a aussi échoué.
La solution consistait à aller dans le repo-browser de Tortoise, trouver le fichier et utiliser la fonction pause.