Erreur de travail bloquée dans tortoise svn lors de la validation

J’utilise Tortoise SVN pour mettre à jour et valider les modifications du référentiel sur le serveur chaque fois que je modifie ma copie de travail. Mais à partir de quelques jours, je ne suis plus en mesure de commettre les modifications et j’obtiens l’erreur suivante chaque fois que j’essaie de commettre.

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 cliquant dessus avec le bouton droit de la souris et en sélectionnant Tortoise SVN> Release lock

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:

  • Accédez au dossier SVN 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 “Verrouiller les verrous” est sélectionnée dans la boîte de dialog Nettoyage.

La réponse acceptée n’a pas fonctionné pour moi. Pour résoudre ce problème, je devais cliquer avec le bouton droit sur le fichier qui était verrouillé, sélectionnez repo-browser . Cela a ouvert une fenêtre avec les fichiers tels qu’ils sont sur le serveur SVN. J’ai ensuite cliqué avec le bouton droit sur le fichier verrouillé et sélectionné le break lock .

Lorsque j’ai fermé le navigateur de référentiel, je pouvais enfin valider sur explorer!

  1. Faites un clic droit sur le dossier.
  2. TortoiseSVN-> Vérifiez les modifications.
  3. Cliquez sur le bouton Vérifier le référentiel.
  4. Verrouiller tous les fichiers renvoyés.

J’ai également rencontré ce problème. Pour certains, j’aimerais souligner que s’il est verrouillé, VÉRIFIEZ VOTRE ÉQUIPE. Quelqu’un dans l’équipe peut avoir des choses verrouillées parce qu’il travaille dessus (cela permet aux développeurs de travailler sur des choses sans que d’autres utilisateurs ne viennent travailler sur le même contenu). Si tel est le cas, la libération du verrou et la mise à jour risquent de perdre des données pour le développeur qui l’a verrouillé.

Dans cette optique, mon inquiétude était que l’option “nettoyage” pourrait éventuellement modifier ma copie de travail ou supprimer des informations du niveau Repo de Subversion. Ce n’est pas le cas. La réponse a fonctionné pour moi. Le mien a été verrouillé lorsque j’ai cliqué sur Annuler au milieu d’une mise à jour. J’ai fini par tirer certaines de nos succursales et je n’avais pas besoin de ces trucs alors j’ai frappé annulation. Ma copie de travail est devenue verrouillée. Je n’ai pas pu trouver de documents “bloqués” lorsque j’ai utilisé la commande “release lock”. Cela m’a laissé perplexe et après quelques lectures rapides (et ce fil), j’ai tenté la commande «nettoyage». Après un nettoyage, cela a résolu mon problème et rien n’était plus verrouillé.

source: http://tortoisesvn.net/docs/nightly/TortoiseSVN_en/tsvn-dug-locking.html

Il y a plusieurs significations de “verrouiller” dans SVN et certaines de ces réponses qui parlent de “locking” ou d’un coéquipier détenant un verrou n’utilisent pas la signification pertinente pour la question d’origine. Cette question concerne les «verrous de copie de travail» (c’est-à-dire qu’ils sont entièrement locaux à la copie de travail sur votre ordinateur et n’ont rien à voir avec vous ou vos coéquipiers détenant un locking / extraction sur un fichier). La réponse acceptée par MicroEyes fait référence à l’utilisation correcte et est 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 devrez les copier sur la nouvelle copie de travail afin de ne pas perdre vos modifications.

Voir cette page dans la documentation de 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 sens de «Lock»

Dans cette section, et presque partout dans ce livre, les mots «verrouiller» et «verrouiller» décrivent un mécanisme d’exclusion mutuelle entre utilisateurs pour éviter les commits contradictoires. Malheureusement, il existe deux autres types de «verrous» avec lesquels Subversion, et donc ce livre, doivent parfois être concernés.

Le second est le travail des verrous de copie , utilisés en interne par Subversion pour éviter les conflits entre plusieurs clients Subversion fonctionnant sur la même copie de travail. Habituellement, vous obtenez ces verrous chaque fois qu’une commande comme 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 quel fichier contenait la serrure, alors je me suis débrouillé pour sortir de ce problème:

  1. Je suis allé au plus haut niveau du dossier
  2. Click clean-up et coché par les méthodes de nettoyage -> Break Locks

Cela a fonctionné pour moi.

J’avais essayé différentes choses, y compris “Clean Up” sur les sous-répertoires inférieurs. Enfin, j’ai essayé de mettre à jour le dossier de niveau supérieur. Rien. Ensuite, je lis le conseil “Nettoyer le niveau supérieur”. J’ai essayé ça. La partie de nettoyage a réussi, mais la serrure est restée. Ma solution consistait à retourner au plus haut niveau, à nettoyer, puis à nettoyer chaque dossier rouge (!) Que je pouvais explorer . Après tout était “nettoyé”, la mise à jour fonctionnait parfaitement. L’astuce “break lock” est également intéressante, sauf que quelqu’un dans votre équipe peut avoir un verrou légitime.

J’ai réussi à m’enfermer dans un fichier dans svn – je ne sais pas comment – mais quand j’ai essayé de (re) mettre le verrou (Tortoise montrait l’option “Get Lock” pour le fichier), il s’est plaint d’avoir déjà le 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 rafraîchir la superposition), mais cela a également échoué.

La solution consistait à entrer dans le repo-browser de Tortoise, à trouver le fichier et à utiliser la fonction de locking du break .

Solution Windows:

https://sourceforge.net/projects/win32svn/

1.Téléchargez-le, puis ajoutez-le au chemin du système.

2. Allez dans le répertoire de travail exécutez “svn clean” et “svn update” dans cmd.