La copie de travail XXX est verrouillée et le nettoyage a échoué dans SVN
Je reçois 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 puis-je sortir de cette boucle?
Une approche serait de:
- Copier les éléments modifiés vers un autre emplacement.
- Supprimez le dossier contenant le chemin du problème.
- Mettez à jour le dossier contenant via Subversion.
- Copiez vos fichiers ou fusionnez les modifications si nécessaire.
- Commettre
Une autre option consisterait à supprimer le dossier de niveau supérieur et à extraire à nouveau. Espérons que cela n’arrive pas à cela.
Pour moi, le truc était de lancer 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.
Regardez dans votre dossier .svn, il y aura un fichier nommé lock. Supprimez ce fichier et vous pourrez le mettre à jour. Il peut y avoir plusieurs fichiers de verrouillage dans le répertoire .svn de chaque sous-répertoire. Ils devront également être supprimés. Cela pourrait être fait comme un lot très simplement à partir de la ligne de commande avec par exemple.
find . -name 'lock' -exec rm -v {} \;
Notez que vous éditez manuellement des fichiers dans le dossier .svn. Ils ont été mis là pour une raison. Cette raison pourrait être une erreur, mais sinon, vous pourriez endommager votre copie locale.
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
Après le commentaire de eakkas , vous devrez peut-être également supprimer toutes les entrées de la table WORK_QUEUE.
Le moyen le plus simple:
- Allez dans le répertoire parent (dossier) du projet .
- Pres Clic droit
- Appuyez sur TortoiseSVN puis appuyez sur Nettoyer ...
- La boîte de dialogue de nettoyage apparaîtrait automatiquement
- Sélectionnez
Clean up working copy status,Break locks,Fix time stamps,Vacuum pristine copies,Refresh Shell overlays,Include externals - Pres OK
Vous avez fait votre travail avec succès.
Vérifiez les captures d'écran pour votre référence.
Première étape:
Deuxième étape: Activez l'option Verrouillage de l'interruption (deuxième case à cocher dans la fenêtre contextuelle de nettoyage) 
J'espère que cela vous aidera beaucoup.
Un collègue au travail voit constamment ce message. Pour lui, c’est parce qu’il a supprimé un répertoire sous contrôle de version SVN sans le supprimer de SVN, puis il a créé un nouveau répertoire à sa place, pas sous contrôle de version, avec Le même nom.
Si c'est votre problème ...:
Il existe différentes façons de résoudre ce problème, en fonction de la manière dont/pourquoi le répertoire a été remplacé.
De toute façon, vous devrez probablement:
A) Renommez le répertoire existant en un nom temporaire
B) Effectuez une inversion de SVN pour récupérer le répertoire supprimé du système de fichiers, mais pas de SVN
De là, vous pouvez soit
A) Copiez les fichiers pertinents 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 de SVN sur l'original, validez et renommez votre nouveau répertoire avec le nom souhaité, suivi d'un ajout de SVN pour obtenir cela un sous contrôle de version.
Pour moi, aucune des solutions ci-dessus n'a fonctionné. J'ai trouvé une solution en cassant les serrures. Lorsque j'ai effectué svn cleanup, j'ai sélectionné "Break Locks" ainsi que "Nettoyer le statut de la copie de travail".
Celui-ci a fonctionné pour moi.
- Allez dans le dossier racine,
- Clic droit et nettoyage
- Vérifier toutes les options disponibles
- Appuyer sur OK
Après le nettoyage, il vous permettra de mettre à jour à la dernière version.
Pour moi, c'était en fait la faute de Tortoise, en quelque sorte. Tortoise vient de se plaindre "ne peut pas nettoyer, lancez le nettoyage", mais quand j'ai exécuté la ligne de commande (svn cleanup), il m'a clairement dit qu'il ne pouvait pas supprimer certains fichiers 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 conserver des fichiers ouverts dans le référentiel à l'origine de ce problème. Tenir un fichier XLS ouvert dans Excel était un coupable dans un autre cas. Il serait donc sage de fermer tous les programmes pouvant utiliser quoi que ce soit dans le référentiel ou même le redémarrage pour forcer les programmes à se fermer puis à réessayer le nettoyage.
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é svn: externals dans laquelle la destination est un dossier existant (versionné ou non), vous obtiendrez l'erreur verrouillée SVN Woring Copy. 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 dans lequel la propriété svn: externals est définie. Cela créera le dossier et tout ira bien à nouveau.
Ce problème s'est posé à moi parce que svn: externals for files requiert que le dossier de destination soit sous contrôle de version. Après avoir constaté que cela ne fonctionnait pas sur différents référentiels, j'ai transféré des fichiers externes vers un dossier externe et je me suis retrouvé dans ce pétrin.
Le moyen le plus simple consiste à afficher les dossiers cachés, puis à ouvrir le dossier .SVN. Vous devriez voir un fichier zéro KB nommé "lock" supprimer ce qui va résoudre le problème
J'ai rencontré exactement le même problème avec SVN 1.7 et aucune des corrections mentionnées ci-dessus ne fonctionnait.
Avant tout, assurez-vous de sauvegarder tout votre contenu édité.
Après avoir passé quelques heures (je n'ai pas tout téléchargé à nouveau, ma branche ayant une taille supérieure à 6 Go), j'ai constaté 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 de base de données (j’ai utilisé le plugin sqlite manager de firefox) et accédez à la table WC_LOCK. Cette table aura les entrées pour les verrous acquis. Supprimez les enregistrements de la table et vous avez terminé :)
Je l'ai fait en créant simplement un nouveau dossier, en extrayant le projet, en copiant les fichiers mis à jour dans le nouveau dossier.
Il a été corrigé avec une nouvelle caisse.
Si vous êtes sur une machine Windows, affichez le référentiel via un navigateur et vous verrez peut-être deux fichiers portant le même nom de fichier mais 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 que le même fichier est extrait, mais Subversion ne le fait pas. Supprimez les noms de fichiers en double sur le référentiel et réessayez.
Lorsque 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 lancerai à nouveau le nettoyage à partir de la racine de travail, qui se plaindra d'un autre répertoire. et je répète juste jusqu'à ce qu'il arrête de se plaindre.
Dans les versions sous Mac OS: Action -> Nettoyer les verrous de la copie de travail à ...
supprimez simplement les dossiers .svn, puis exécutez un nettoyage du répertoire parent. Fonctionne parfaitement!!
J'ai souvent un tel problème. Mon modèle qui cause des problèmes de nettoyage.
- J'ouvre le fichier image dans la visionneuse.
- Je supprime le fichier image/dossier.
- J'essaie de commettre/mettre à jour
Fermer le visualiseur d'images lorsque 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 crois que redémarrer l'ordinateur peut aider dans de tels cas.
Utilisez-vous TortoiseSVN et venez-vous de mettre à jour? J'ai déjà eu ce problème avant de passer de 1.4 à 1.5 sans redémarrer. (Essayez un redémarrage).
La raison pour laquelle vous avez besoin de redémarrer est parce que le fichier cache devient tout à fait génial.
Sinon, pour continuer, exportez cette copie de travail dans un nouveau dossier (ne copiez pas les dossiers cachés .svn), re-récupérez le projet et déplacez tout votre code, puis procédez à votre validation.
La désversion 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 démultiplication sur place, faites glisser le dossier racine de la copie de travail de la liste des fichiers sur lui-même dans l'arborescence, puis 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 de dé-versionner la copie de travail.
Après la conversion, 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 effectuez une extraction 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 peut être une bonne idée).
Un avertissement: si la copie de travail contient des versions mixtes ou des modifications de propriétés non validées, ces informations seront perdues. Pour moi, ce n'est pas chose courante et, étant donné le choix d'une copie de travail corrompue ou la perte de modifications de propriétés non validées, j'ai tendance à opter pour cette dernière.
SVN met normalement à jour sa structure interne (.svn/prop-base) des fichiers d'un dossier avant que les fichiers réels ne soient récupérés du référentiel. Une fois que les fichiers sont récupérés, cela sera effacé. Souvent, l'erreur est générée car la "mise à jour" a échoué ou a été annulée prématurément au cours de la progression de la mise à jour.
- Vérifiez que tous les fichiers sont répertoriés dans le répertoire .svn/prop-base
- Supprimer tous les fichiers qui ne sont pas sous le dossier
- Nettoyer
- Mise à jour
Maintenant, la mise à jour devrait fonctionner.
Faire le ménage
Supprimez le dossier .svn.
Faites le svncheckout dans le dossier racine.
Essayez d'effectuer l'opération de nettoyage.
Cela a résolu mon problème.
J'ai eu ce problème où le "nettoyage" a fonctionné, mais la "mise à jour" continuerait à échouer. La solution qui a fonctionné a été de supprimer le dossier en question via l'Explorateur Windows, et non de supprimer TortoiseSVN (qui marque la suppression comme un élément à valider dans le référentiel, puis j'ai effectué une "extraction" pour essentiellement "mettre à jour" le dossier à partir 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:
Quand TortoiseSVN → supprime un fichier, celui-ci 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 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. Toutefois, 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.
Dans l'explorateur de solutions, cliquez avec le bouton droit de la souris sur le projet. Dans le sous-menu d'ouverture, cliquez sur Subversion et sélectionnez Nettoyer. Cela résoudra le problème, comme cela a été le cas pour moi. J'espère que ça va marcher.
Si vous êtes sur Linux, essayez ceci:
find "/the/path/to/your/directory" -name .svn -type d | xargs chmod 0777 -R
Ensuite, exécutez la commande cleanup sur ce répertoire, puis essayez de mettre à jour.
J'ai fait ce qui suit pour résoudre mon problème:
- Renommé le dossier incriminé en plaçant un "_" devant le nom du dossier.
- A fait un "nettoyage" du dossier parent.
- A renommé le dossier incriminé en son nom d'origine.
- Fait un commit.
Pour moi, le problème était avec le disque complètement plein (les inodes de Linux dans mon cas), quand j'ai supprimé certains dossiers, il a recommencé à fonctionner.
L'erreur était la suivante (sur toute action svn):
$ svn cleanup
svn: E155004: Run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
svn: E155004: Working copy locked; try running 'svn cleanup' on the root of the working copy ('/my/directory') instead.
svn: E155004: Working copy '/my/directory' locked
svn: E200030: sqlite[S14]: unable to open database file
svn: E200030: Additional errors:
svn: E200030: sqlite[S14]: unable to open database file
Ne supprimez pas votre solution!
dans le dossier .svn vous avez un fichier appelé lock, il a une longueur de 0 octet
Vous pouvez supprimer tous ces fichiers de tous les dossiers .svn de votre solution et cela fonctionnera.
Cela a fonctionné dans mon cas
J'avais ceci sous TortoiseSVN et l'erreur était liée à un nouveau répertoire que j'avais créé sous un nouveau projet. Je venais de créer ce projet, il était donc impossible que ce répertoire existe auparavant. J'ai regardé dans le navigateur de référentiel et le nouveau dossier était en effet déjà dans le référentiel, mais TortoiseSVN ne l'a pas montré comme étant validé.
Afin de contourner le problème, comme je venais tout juste de créer le dossier, je l'ai supprimé dans le référentiel, puis j'ai effectué une validation. Cela a bien fonctionné.
Comme je l’avais fait en dehors de Visual Studio, je devais ensuite redémarrer Visual Studio pour que tout soit à nouveau détecté.
Je sais que c'est un très vieux fil mais je maintiens que:
La méthode la plus simple et la plus sûre pour résoudre ce problème consiste à supprimer votre dossier ".svn" masqué et à tout vérifier à nouveau.
Il corrige la plupart des problèmes lorsque les svn vis autour devraient conserver les modifications locales (marquées comme "en conflit") lorsque vous relancez la révision principale.
La mise à jour des autorisations de répertoire (octroi d'un accès en écriture) résout également le problème.
chmod +w <dir_name>
Une des raisons de ce problème que je n'ai pas vu dans les réponses est qu'un update ou checkout peut avoir été utilisé avec d'autres utilisateurs/autorisations, comme par exemple avec $Sudo.
J'ai eu le même problème. Il semble que cela ait été corrigé dans les dernières versions. J'ai mis à jour mon Tortoise SVN vers la dernière version (1.7.11) et clean up a bien fonctionné.
Vous pouvez télécharger la dernière version ici: télécharger tortoise svn .
@ La solution de Chuck n'était pas pratique pour moi. La première fois que j'ai eu le problème, cela a fonctionné mais cela a aussi donné beaucoup de travail supplémentaire. Dans le second cas, j'ai changé de charge de fichier lorsque j'utilisais mon ordinateur portable en dehors du réseau. Je ne pouvais pas voir mon dossier aller dossier par dossier après la modification des fichiers. Avait espoir sur la tortue et a travaillé. Regardez comment:
L'environnement était:
- Visual Studio 2008
- Ankhsvn
Procédure:
- D'abord, je ne pouvais pas commettre, il a dit que je devais nettoyer
- Deuxièmement, je ne pouvais pas nettoyer, il y avait un dossier sur le svn - "bin"
- J'ai téléchargé la dernière version de Tortoise, j'ai essayé et je ne travaille pas à cause du dossier dammed.
- Renommé ce dossier et je pourrais maintenant mettre à jour le référentiel local avec la dernière version.
- Quelques fichiers sont entrés.
- Est-ce que le commit et a travaillé.
Étapes:
Fermez tous les fichiers d'édition du dossier svn
Fermez Eclipse ou n’importe quel éditeur utilisant un dossier ou un fichier du répertoire svn.
Faites un clic droit sur le dossier svn check out et cliquez sur le déverrouillage.
Faites un clic droit sur le dossier svn check out et cliquez sur nettoyer.
Votre SVN est prêt pour les opérations de validation et de mise à jour de SVN.
Acclamations:)
Démarrer la recherche .... Verrouiller ... Sélectionner tous les fichiers de la liste et supprimer..fixed
Nettoyer n'est certainement pas suffisant pour résoudre ce problème parfois.
Si vous utilisez TortoiseSVN version 1.7.2 ou supérieure, cliquez avec le bouton droit de la souris sur le répertoire parent du fichier verrouillé et sélectionnez TortoiseSVN -> Navigateur Repo dans le menu. Dans l’interface graphique de Repro Browser, cliquez avec le bouton droit de la souris sur le fichier verrouillé. Une option permet de supprimer le verrou.
ce qui suit devrait faire:
svn status | grep ". L" | sed 's /.* (. *) $/\ 1 /' | awk '{longueur d'impression (1 $), 1 $}' | trier -nr | awk '{print "pushd" $ 2 "; svn cleanup; popd"}' | sh
Spotlight est son quotidien habituel pour trouver les fichiers de verrouillage de manière récursive.
EasyFind sur le Mac App Store fonctionne
http://iTunes.Apple.com/gb/app/easyfind/id411673888?mt=12
rechercher 'lock'
Sélectionner tout/Supprimer