La copie de travail XXX a été verrouillée et le nettoyage a échoué dans SVN


582

J'obtiens cette erreur lorsque je fais un svn update:

Copie de travail XXXXXXXX verrouillée Veuillez exécuter la commande "Nettoyage"

Quand je lance le nettoyage, je reçois

Le nettoyage n'a pas pu traiter les chemins suivants: XXXXXXXX

Comment sortir de cette boucle?


5
J'ai aussi reçu ce message. Les réponses fournies semblaient un peu fastidieuses (en particulier la réponse la plus élevée). Je viens de fermer VS et de relancer la solution et j'ai pu tout vérifier très bien.
oscilatingcretin

Le commentaire suivant de eakkas pour supprimer les entrées de la table WORK_QUEUE à l'aide du gestionnaire SQLLite de Firefox a résolu le problème pour moi.
zeppelin

12
Il y a une réponse simple, il suffit de cocher l'option "briser les verrous" et cela nettoiera votre copie de travail
Farhan

Réponses:


517

Une approche consisterait à:

  1. Copiez les éléments modifiés vers un autre emplacement.
  2. Supprimez le dossier contenant le chemin du problème.
  3. Mettez à jour le dossier contenant via Subversion.
  4. Copiez vos fichiers ou fusionnez les modifications selon vos besoins.
  5. Commettre

Une autre option consisterait à supprimer le dossier de niveau supérieur et à reprendre. Espérons que cela n'arrive pas à cela.


123
+1 à vous pour cette solution de contournement pour résoudre non seulement le problème de l'OP (et le mien), mais aussi pour donner les 5 étapes qui semblent résoudre tout problème svn. -1 à subversion pour les solutions de contournement nécessaires.
pxl

34
Bien que cela fonctionne techniquement, c'est une si mauvaise façon de le faire par rapport à la suppression des verrous qu'il mérite un downvote.
Jukka Dahlbom

8
Je ne peux pas faire l'étape 3 car ... "La copie de travail est déjà verrouillée"
Evgeny

20
Considérez les conseils de BradS "Pour moi, l'astuce était d'exécuter" svn cleanup "en haut de ma copie de travail, pas dans le dossier où j'avais travaillé tout le temps avant que le problème ne se produise."
Marco

5
Pour ceux qui utilisent Tortoise SVN, vous pouvez exécuter un nettoyage sur le dossier racine du répertoire d'extraction et forcer Break Locks. De plus, vous pouvez lui demander de supprimer les fichiers non versionnés. Faites ensuite une mise à jour.
Obaid

476

Pour moi, l'astuce consistait à exécuter svn cleanupen haut de ma copie de travail, pas dans le dossier où j'avais travaillé tout le temps avant que le problème ne se produise.


fonctionne généralement mais ne fonctionne plus, je ne sais pas si c'est parce que je suis passé à SVN 1.7
Populus

4
cela a fonctionné pour moi avec un client exécutant 1.7, bien que le serveur soit toujours 1.6.x
Mark Hosang

A travaillé pour moi sur 1.7 très apprécié
scarpacci

1
J'ai combiné l'indice de la réponse d'Intu avec celui-ci: recherchez le dossier parent qui a un fichier "lock" dans son dossier .svn, puis exécutez "svn cleanup" là-bas. Cela a fonctionné pour moi.
rob74

5
Cela fonctionne pour moi, de manière beaucoup plus rapide que celle de Chuck. Il vaut donc la peine de faire celui-ci en premier.
goamn

210

Regardez dans votre .svndossier, il y aura un fichier appelé lock. Supprimez ce fichier et vous pourrez le mettre à jour. Il peut y avoir plus de fichiers de verrouillage dans le .svnrépertoire de chaque sous-répertoire. Ils devront également être supprimés. Cela pourrait être fait en tant que lot tout simplement à partir de la ligne de commande avec par exemple

find . -name 'lock' -exec rm -v {} \;

Notez que vous modifiez manuellement les fichiers du .svndossier. Ils ont été placés là pour une raison. Cette raison pourrait être une erreur, mais sinon, vous pourriez endommager votre copie locale.

SOURCE: http://www.svnforum.org/2017/viewtopic.php?p=6068


8
+1 Je pense que c'est une bien meilleure approche que la réponse actuellement la plus votée - je déteste devoir copier les fichiers ailleurs d'abord pour contourner ce problème (commun!). Le mien a été provoqué par un outil de génération de code générant des fichiers avec le même nom que quelqu'un d'autre avait déjà ajouté à SVN. Mon mauvais pour pas "svn up" d'abord je suppose ...
alpian

44
Cela ne fonctionne plus avec Tortoise / SVN 1.7 (ou du moins je n'ai trouvé aucun fichier de verrouillage car il y a maintenant une base de données centralisée avec les métadonnées).
pesche

10
voici une ligne rapide qui devrait supprimer récursivement tous les verrous commençant dans le répertoire actuel:find . | grep ".svn/lock" | xargs rm
Jesse

1
Avec SVN 1.7, la réponse de @ BradS semble plus efficace. Cette réponse n'a pas fonctionné pour moi, et BradS l'a fait.
Ira Baxter

1
Dans mon cas, il n'y a aucun fichier de verrouillage nulle part.
Tim MB

106

Dans mon cas, je l'ai résolu en supprimant manuellement un enregistrement dans l'enregistrement de verrouillage de fichier SQLite ".svn \ wc" dans la table WC_LOCK.

J'ai ouvert le fichier "WC" avec l'éditeur SQLite et exécuté

delete from WC_LOCK

capture d'écran montrant toutes les entrées supprimées de WC_LOCK

Suite au commentaire d' eakkas , vous devrez peut-être également supprimer toutes les entrées du WORK_QUEUEtableau.


1
Cela a fonctionné pour moi pour Subversion 1.7.5 sur Windows. Version d'essai téléchargée de SQLite Expert à partir d'ici: sqliteexpert.com/download.html . Exécutez l'instruction sql "supprimer" ci-dessus dans l'onglet SQL.
M Katz

C'est beaucoup mieux, une seule différence est que j'ai cliqué sur le bouton rouge (-)
Rohit Srivastava

3
Un espion DI SQL gratuit ferait également l'affaire: yunqa.de/delphi/doku.php/products/sqlitespy/index
Ivelin Nikolaev

12
Cela a également fonctionné pour moi, mais j'ai également dû purger les entrées de la table
WORK_QUEUE

6
Cela n'a pas fonctionné en supprimant l'élément de WC_LOCK - ce qui a fonctionné, c'était le contenu blob de mon élément WORK_QUEUE et bien sûr, c'était le fichier de problème - j'ai supprimé le fichier du navigateur de référentiel puis supprimé l'élément work_queue - après cela a effectué un nettoyage et a repris ses activités!
GregM

95

La façon la plus simple qui soit:

  1. Accédez au répertoire parent (dossier) du projet .
  2. Pres Clic droit
  3. Appuyez sur TortoiseSVN puis appuyez sur Nettoyer ...
  4. La boîte de dialogue de nettoyage apparaîtra automatiquement
  5. Sélectionnez Clean up working copy status, Break locks, Fix time stamps, Vacuum pristine copies, Refresh shell overlays,Include externals
  6. Pres OK

Vous avez fait votre travail avec succès.

Vérifiez les captures d'écran pour votre référence.

Premier pas:

entrez la description de l'image ici

Deuxième étape: activez l'option de verrouillage du verrouillage (deuxième case à cocher dans la fenêtre contextuelle de nettoyage) entrez la description de l'image ici

J'espère que cela vous aidera beaucoup.


10
dans mon cas, l'option "Break lock" était suffisante, essayez peut-être d'abord avec celle-ci uniquement
Donatello

Bonne réponse. J'ai eu un cas de «cécité de dialogue» avec celui-ci et je n'ai jamais vérifié les options de nettoyage. Historiquement, «naviguer vers root et nettoyer» fonctionnait auparavant, mais je suppose que briser les verrous était suffisant dans mon cas.
Phil Cooper

1
A aussi fonctionné pour moi!
Daniel Silva

Je ne pensais pas que «casser les verrous» le ferait, car je n'ai fait aucun verrou. Mais apparemment, il casse les verrous internes svn qui causaient ce problème. Merci!
basher

N'a pas fonctionné pour moi 😦
Warlike Chimpanzee

48

Un collègue de travail voit constamment ce message, et pour lui, c'est parce qu'il a supprimé un répertoire sous contrôle de version SVN sans le supprimer de SVN, puis a créé un nouveau répertoire à sa place non sous contrôle de version, avec le même nom.

Si c'est votre problème ...:

Il existe différentes façons de le corriger, selon la façon / pourquoi le répertoire a été remplacé.

Dans tous les cas, vous devrez probablement:

A) Renommez le répertoire existant en un nom temporaire

B) Faire un retour SVN pour récupérer le répertoire supprimé du système de fichiers, mais pas de SVN

De là, vous feriez soit

A) Copiez les fichiers appropriés dans le répertoire qui a été supprimé

B) Si vous avez eu un changement important de contenu dans le répertoire, effectuez une suppression SVN sur l'original, validez et renommez votre nouveau répertoire au nom souhaité, suivi d'un ajout SVN pour obtenir celui- ci sous contrôle de version.


1
Votre deuxième étape B) me semble une très mauvaise idée, car elle casserait l'historique des révisions pour les éléments du répertoire d'origine qui sont conservés dans la nouvelle version.
Dunaril

Les très mauvaises choses se sont produites lorsque la personne a supprimé un répertoire versionné du système de fichiers mais pas de SVN. La réponse ci-dessus n'est peut-être pas une récupération parfaite, mais c'est une récupération.
Teemu Leisti

34

Pour moi, aucune des solutions ci-dessus n'a fonctionné. J'ai trouvé une solution en cassant les verrous. Lorsque j'ai effectué le nettoyage de svn, j'ai sélectionné "Break Locks" avec "Clean up working copy status".

entrez la description de l'image ici


Pour moi, le verrouillage du navigateur de dépôt Tortoise SVN a fonctionné. Briser le verrou sur le dossier extrait n'a rien fait.
Bhargava Mummadireddy

23

Celui-ci a fonctionné pour moi.

  1. Accédez au dossier racine,
  2. Clic droit et nettoyage
  3. Vérifier toutes les options disponibles
  4. Appuyer sur OK

Après le nettoyage, il vous permettra de passer à la dernière version.


2
Cela fonctionne aussi pour moi. Vous devez vérifier toutes les options disponibles (6 entrées dans ma version) pour procéder au nettoyage; il échoue si vous cochez simplement les options [Nettoyer l'état de la copie de travail] et [Inclure les éléments externes].
Vincent Jia

1
Cela a totalement fonctionné pour moi ... juste par un clic droit sur le projet> Équipe> Nettoyage. Je n'ai eu à supprimer aucune ligne du SQL dans .svn ni rien d'autre. C'est exactement ce qui a fait le travail. Merci!
msqar

Cela a également fonctionné pour moi dans la version 1.7.4 de TortoiseSVN. Je suis allé avec les cases à cocher par défaut qui ont été présentées.
slm

M'a aidé aujourd'hui, mais je n'avais pas besoin de vérifier toutes les options disponibles. Les trois derniers qui ont annulé mes modifications, je n'ai pas vérifié, et cela a quand même fonctionné. Voir aussi stackoverflow.com/a/35192644/460775
EMBarbosa

1
Cela a fonctionné pour moi. Je viens de vérifier Clean up working copy statuset Breaks locksetInclude externals
Phiber

11

Pour moi, c'était en fait la faute de Tortoise. Tortoise vient de se plaindre "ne peut pas nettoyer, exécuter le nettoyage", mais lorsque j'ai exécuté la ligne de commande (nettoyage svn), elle m'a clairement dit qu'elle ne pouvait pas supprimer certains fichiers qui étaient en cours d'utilisation, la solution était évidente. Une fois que j'ai fermé Visual Studio (qui gardait les fichiers ouverts), le nettoyage a bien fonctionné.

D'autres programmes peuvent également garder des fichiers ouverts dans le référentiel à l'origine de ce problème. Excel tenant un xls ouvert était un coupable dans une autre instance, il peut donc être judicieux de fermer tous les programmes qui peuvent utiliser quoi que ce soit dans le référentiel ou même de redémarrer pour forcer les programmes à se fermer, puis réessayer de nettoyer.


7

J'ai eu ce problème parce que les dossiers externes ne veulent pas être liés à un dossier existant. Si vous ajoutez une ligne de propriétés svn: externals où la destination est un dossier existant (avec ou sans version), vous obtiendrez l'erreur SVN Woring Copy verrouillée. Ici, un nettoyage vous indiquera également que tout est correct mais que la mise à jour ne fonctionnera pas.

Solution: supprimez le dossier problématique du référentiel et effectuez une mise à jour dans le dossier racine où la propriété svn: externals est définie. Cela va créer le dossier et tout ira bien à nouveau.

Ce problème est survenu pour moi car svn: externals pour les fichiers nécessite que le dossier de destination soit contrôlé par la version. Après avoir remarqué que cela ne fonctionne pas dans différents référentiels, j'ai échangé des fichiers externes vers un dossier externe et suis entré dans ce pétrin.


6

La façon la plus simple de procéder consiste à afficher les dossiers cachés, puis à ouvrir le dossier .SVN. Vous devriez voir un fichier de zéro Ko nommé "verrou" supprimer cela résoudra le problème


5

J'ai rencontré exactement le même problème en utilisant SVN 1.7 et aucun des correctifs mentionnés ci-dessus n'a fonctionné.

Avant tout, assurez-vous de sauvegarder tout votre contenu modifié.

Après avoir passé quelques heures (ne pas tout retélécharger car ma branche fait plus de 6 Go), j'ai trouvé qu'il y avait un fichier db appelé "wc" dans le dossier .svn de votre branche.

Ouvrez le fichier db en utilisant n'importe quel gestionnaire db (j'ai utilisé le plugin sqlite manager de Firefox) et accédez à la table WC_LOCK. Ce tableau contiendra les entrées pour les verrous acquis. Supprimez les enregistrements de la table et vous avez terminé :)


même si c'était à peu près un double de la réponse précédente, je vous ai donné un vote parce que vous avez mentionné le plugin firefox SQLite manager.
ehambright

3

Quand j'ai ce problème, je trouve que l'exécution de la commande de nettoyage directement sur le chemin du problème semble généralement fonctionner. Ensuite, je vais exécuter à nouveau le nettoyage à partir de la racine de travail, et il se plaindra d'un autre répertoire. et je répète juste jusqu'à ce qu'il cesse de se plaindre.


1
Je n'ai pas pu trouver un fichier de verrouillage comme avec les réponses précédentes, mais cela a fonctionné pour moi :)
serenskye

3

Si vous êtes sur une machine Windows, affichez le référentiel via un navigateur et vous pouvez bien voir deux fichiers avec le même nom de fichier mais en utilisant des cas différents. Subversion est sensible à la casse et Windows ne l'est pas, vous pouvez donc obtenir un verrou lorsque Windows pense qu'il tire vers le bas le même fichier et Subversion ne le fait pas. Supprimez les noms de fichiers en double dans le référentiel et réessayez.


3

Je l'ai fait en créant simplement un nouveau dossier, en vérifiant le projet, en copiant les fichiers mis à jour dans le nouveau dossier.

Il a été corrigé avec un nouveau paiement.


J'ai fait la même chose. (Je mets la cause racine à AnkhSVN en train de jouer avec ma copie de travail. AnkhSVN est maintenant désinstallé).
Scotty.NET

2

Utilisez-vous TortoiseSVN et venez-vous de le mettre à jour? J'ai déjà eu ce problème avant de passer de 1.4 à 1.5 et de ne pas redémarrer. (Essayez un redémarrage).

La raison pour laquelle vous devez redémarrer est parce que le fichier cache devient tout génial.

Sinon, pour continuer, exportez cette copie de travail dans un nouveau dossier (ne copiez pas les dossiers cachés .svn), récupérez à nouveau le projet et déplacez tout votre code en arrière, puis procédez à votre validation.


Cela m'est arrivé aussi, c'est-à-dire que je devais juste redémarrer
Matthew Lock

2

supprimez simplement les dossiers .svn, puis exécutez un nettoyage sur le répertoire parent. Marche parfaitement!!


3
Dans SVN 1.7, cela ne fonctionnera pas car il n'y a qu'un seul dossier .svn, en haut. S'il est supprimé, la pièce jointe au référentiel est supprimée.
AnneTheAgile

2

Dans les versions sous Mac OS: Action -> Nettoyer les verrous de copie de travail à ...


2

J'ai souvent un tel problème. Mon modèle qui cause des problèmes de nettoyage.

  1. J'ouvre le fichier image dans la visionneuse.
  2. Je supprime le fichier / dossier d'image.
  3. J'essaie de valider / mettre à jour

La fermeture de la visionneuse d'images où le fichier supprimé est ouvert résout le problème. Peut-être que d'autres logiciels peuvent bloquer le nettoyage de la même manière.

En général. Je pense que le redémarrage de l'ordinateur peut aider dans de tels cas.


1

SVN met normalement à jour sa structure interne (.svn / prop-base) des fichiers dans un dossier avant que les fichiers réels ne soient récupérés du référentiel. Une fois les fichiers récupérés, cela sera effacé. L'erreur est fréquemment renvoyée car la "mise à jour" a échoué ou a été annulée prématurément pendant la progression de la mise à jour.

  1. Vérifiez que tous les fichiers sont répertoriés dans le répertoire .svn / prop-base
  2. Supprimez tous les fichiers qui ne se trouvent pas dans le dossier
  3. Nettoyer
  4. Mise à jour

Maintenant, la mise à jour devrait fonctionner.


1

J'ai eu le même problème car j'ai exporté un dossier sous un dossier contrôlé par version. J'ai dû supprimer le dossier de TortoiseSVN, puis supprimer le dossier du système de fichiers (TortoiseSVN n'aime pas les sous-dossiers non versionnés ... pourquoi pas ???)


Je devrais ajouter que j'ai exporté un dossier DANS LE MÊME DOSSIER .. c'est ainsi que vous réversionnez prev. dossiers versionnés.

1

Lancer la recherche .... Verrouiller ... Sélectionner tous les fichiers répertoriés et supprimer..fixé


1

ce qui suit devrait faire:

statut svn | grep ". L" | sed 's /.* (. *) $ / \ 1 /' | awk '{longueur d'impression ($ 1), $ 1}' | sort -nr | awk '{print "pushd" $ 2 "; svn cleanup; popd"}' | sh


1

Ne supprimez pas votre solution!

dans le dossier .svn vous avez un fichier appelé lock il fait 0 octets de long

Vous pouvez supprimer tous ces fichiers de tous les dossiers .svn de votre solution et cela fonctionnera

Cela a fonctionné dans mon cas


Ceci est la solution la plus simple! A travaillé pour moi
Nathan

Oui, malheureusement, cela ne fonctionne pas pour la dernière version de SVN. Pour la dernière version, vous devez le supprimer car il n'y a plus de fichier de verrouillage. il ne semble plus y avoir de fichiers, il existe une toute autre structure de dossiers. Si quelqu'un sait s'il y a quelque chose qui peut encore être modifié d'une manière similaire à celle ci-dessus, veuillez le partager avec nous.
Para

1

La réversion sur place des fichiers et une nouvelle extraction au même endroit ont résolu ce problème pour moi.

Dans TortoiseSVN, pour effectuer une annulation sur place, faites glisser le dossier racine de la copie de travail de la liste des fichiers vers lui-même dans l'arborescence des répertoires et choisissez «Exporter les éléments versionnés SVN ici» dans le menu contextuel. TortoiseSVN remarque que la destination est la même que la source et suggère d'annuler la version de travail.

Après avoir annulé la version, effectuez une nouvelle extraction dans le même dossier (qui contient maintenant une copie non versionnée de tous les fichiers que vous aviez). TortoiseSVN vous avertira que vous extrayez dans un dossier existant, mais vous pouvez continuer.

Après cela, les nettoyages, mises à jour et autres opérations ont fonctionné sans accroc. Étant donné que les deux étapes ci-dessus préservent les modifications locales, il ne devrait pas y avoir de perte d'informations (mais sauvegarder la copie de travail avant cela peut néanmoins être une bonne idée).

Un avertissement: si la copie de travail contient des versions mixtes ou des modifications de propriété non validées, ces informations seront perdues. Pour moi, ce n'est pas un phénomène courant, et étant donné le choix d'une copie de travail corrompue ou la perte de modifications de propriété non validées, j'ai tendance à opter pour cette dernière.


1

J'ai eu ce problème où le "nettoyage" a fonctionné, mais la "mise à jour" continuerait à échouer. La solution qui a fonctionné était de supprimer le dossier en question via l'Explorateur Windows, pas la suppression de TortoiseSVN (qui marque la suppression comme quelque chose à valider dans le référentiel, puis j'ai fait une "vérification" pour essentiellement "mettre à jour" le dossier du référentiel.

Plus d'informations sur la différence entre une suppression O / S et une suppression SVN ici: http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-rename.html

Notamment:

Lorsque vous TortoiseSVN → Supprimer un fichier, il est immédiatement supprimé de votre copie de travail et marqué pour suppression dans le référentiel lors de la prochaine validation.

Et:

Si un fichier est supprimé via l'explorateur au lieu d'utiliser le menu contextuel de TortoiseSVN, la boîte de dialogue de validation affiche ces fichiers et vous permet également de les supprimer du contrôle de version avant la validation. Cependant, si vous mettez à jour votre copie de travail, Subversion repérera le fichier manquant et le remplacera par la dernière version du référentiel.


1

Si vous êtes sous Linux, essayez ceci:

find "/the/path/to/your/directory" -name .svn -type d | xargs chmod 0777 -R

Exécutez ensuite la cleanupcommande sur ce répertoire, puis essayez de mettre à jour.


1

J'ai fait ce qui suit pour résoudre mon problème:

  1. Renommé le dossier incriminé en plaçant un "_" devant le nom du dossier.
  2. A fait un "nettoyage" du dossier parent.
  3. Renommé le dossier incriminé en son nom d'origine.
  4. A commis un commit.

1

Dans l'explorateur de solutions, faites un clic droit sur le projet, dans le sous-menu d'ouverture, cliquez sur subversion et sélectionnez le nettoyage. Cela résoudra le problème, comme pour moi. J'espère que cela fonctionnera.


1

Pour faire le ménage

  1. Supprimez le dossier .svn.

  2. Faites le svncheckout dans le dossier racine.

  3. Essayez d'effectuer l'opération de nettoyage.

Cela a résolu mon problème.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.