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

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?

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.

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.

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

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

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

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:

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

J'espère que cela vous aidera beaucoup.

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.

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".

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.

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.

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.

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

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é :)

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.

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.

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.

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.

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

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

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.

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.

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 ???)

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

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

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

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.

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.

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.

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.

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.

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.