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


Je reçois cette erreur quand je fais un svn update:

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

Quand je cours le nettoyage, je reçois

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

Comment puis-je sortir de cette boucle?


564
2018-02-04 04:41


origine


Réponses:


Une approche serait de:

  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 au besoin.
  5. Commettre

Une autre option serait de supprimer le dossier de niveau supérieur et de vérifier à nouveau. Espérons que cela ne vient pas à ça.


513



Pour moi, l'astuce était de courir 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.


463



Regardez dans votre .svn dossier, il y aura un fichier appelé lock. Supprimer ce fichier et vous serez en mesure de mettre à jour. Il peut y avoir plus de fichiers de verrouillage dans le .svn ré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 dans le .svn dossier. Ils ont été mis là pour une raison. Cette raison pourrait être une erreur, mais sinon vous pourriez endommager votre copie locale.

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


207



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

screenshot showing all entries purged from WC_LOCK

Suivant eakkasle commentaire, vous devrez peut-être supprimer toutes les entrées de WORK_QUEUE table aussi bien.


99



Le moyen le plus simple jamais:

  1. Aller à Répertoire parent (dossier) de Projet.
  2. Pres Clic-droit 
  3. appuyer sur TortoiseSVN puis appuyez Nettoyer...
  4. La boîte de dialogue Nettoyer apparaît automatiquement
  5. Sélectionner Clean up working copy status, Break locks, Fix time stamps, Vacuum pristine copies, Refresh shell overlays, Include externals
  6. Pres D'accord

Vous avez fait votre travail avec succès.

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

Premier pas:

enter image description here

Deuxième étape: Activer l'option de verrouillage de pause (deuxième case à cocher dans la fenêtre contextuelle de nettoyage) enter image description here

J'espère que cela vous aidera beaucoup.


81



Un collègue au 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 pour autant le supprimant de SVN, puis a créé un nouveau répertoire à sa place pas sous le contrôle de version, avec le même nom.

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

Il existe différentes façons de le réparer, en fonction de comment / pourquoi le répertoire a été remplacé.

De toute façon, vous aurez probablement besoin de:

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

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

De là, vous seriez soit

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

B) Si vous avez eu un changement significatif de contenu dans le répertoire, faites une suppression SVN sur l'original, validez, et renommez votre nouveau répertoire au nom désiré, suivi par un SVN add to get cette un sous contrôle de version.


48



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 svn, j'ai sélectionné "Break Locks" avec "Nettoyer le statut de copie de travail".

enter image description here


23



Celui-ci a travaillé pour moi.

  1. Allez dans le dossier racine,
  2. Clic droit et nettoyage
  3. Vérifiez toutes les options disponibles
  4. Appuyer sur OK

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


22



Pour moi, c'était en fait la faute de Tortoise, en quelque sorte. Tortoise s'est plaint "ne peut pas nettoyer, exécuter le nettoyage", mais quand j'ai couru la ligne de commande (nettoyage SVN), il m'a clairement dit qu'il ne pouvait pas supprimer certains fichiers qui étaient en usage, 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 les fichiers ouverts dans le référentiel causant ce problème. Excel tenant un xls ouvert était un coupable dans une autre instance, il peut donc être sage de fermer tous les programmes qui peuvent utiliser quelque chose dans le repo ou même de redémarrer pour forcer les programmes à se fermer et ensuite essayer à nouveau de nettoyage.


11



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

Solution: supprimez le dossier perturbant 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 parce que svn: externals for files nécessite que le dossier de destination soit contrôlé par la version. Après avoir remarqué que cela ne fonctionne pas à travers différents référentiels, j'ai changé de fichiers externes en dossiers externes et suis entré dans ce gâchis.


7